読者です 読者をやめる 読者になる 読者になる

えんじにゃーず・ハイ

主にエンジニアや技術情報についてつらつら書き連ねるブログです

DevOpsハッカソン入門編に参加してきました(2日目)

イベント参加 ハッカソン

DevOps!!DevOps!!

1日目に引き続き2日目にも参加してきました。1日目の様子はこちらから。

40balmung.hatenablog.com

いやー楽しかった!初ハッカソンでしたが、知らない人たちと2日間という短い期間で話し合いながら開発するのは楽しいですね。今後ハッカソンへ参加する良い足掛かりになりました。

道中の問題や所感はさておいて、今回は当チームがどのようにDevOpsを進めたか、また総評も書き残しておきたいと思います。

作成するプロダクトについて

プロダクト概要

プロダクト名:TodoSpam

Todoを管理するWebアプリ。特徴は期限切れになったTodoから催促のスパムメールが飛んでくる。

アーキテクチャ(Dev)

チームにJavaを経験している人が多かったのでサーバーサイドはJavaを選択。JSPJSFなどのサーバーレンダリング技術を採用するとView担当とうまく切り分けができないだろう、とのことでフロントエンドはJavaScriptのみ。サーバーとのやりとりはJSONで行い、サーバーサイドはRESTでJSONを返却する仕組みとした。また、FWは採用せずに生のServletを採用。手軽に作成するならSpringBootもいいかと思われたが、学習コストを掛ける時間がないため不採用。

アーキテクチャ(Ops)

ただのWebアプリなのでサーバーとSQLServerがあればOK。JavaのWebアプリなのでTomcatWildflyなどのAPサーバーがあれば基本的に動く。ロードバランサーやらパフォーマンスモニタやらはサービスができてから考える。というか、アプリ作成がミッションなのでそこまで手が回らないと予想。

  • サーバー
    • なんでも
  • DBサーバー

要件

最初は要件定義としてTodoSpamにどんな機能を付けるのかを話し合いました

などなど。色々上がりましたがまずはシンプルなアプリを作ることに専念しました。

シンプルとは

  • Todo一覧が見れる
  • Todoが期限付きで登録できる
  • Todoの期限が切れたら無慈悲にスパムメールを送信する

以上です。

これらが出来たら、新しい機能として何を追加するか話し合おう、というルールで進めました。

役割分担

当チームはDevOpsハッカソンなのにまさかのDev5人、Ops0人という特殊なチームでした。なのでOpsにも興味がある私ともう一人でOpsに挑戦し、ときおりDevも兼任するという形で役割を分担しました。

  • Dev
    • ビュー担当:1名
    • サーバーサイド担当:2名
  • Ops
    • IaC、継続的デプロイ担当:1名
    • 自動テスト、CI、DB担当:1名

採用するDevOpsプラクティス

DevOpsを実現するには下記プラクティスがあります。

f:id:areph:20160614111502p:plain

この中で採用できそうなところとして

は実現したいと話していました。

開発結果

  • IoC
  • 継続的インテグレーション
    • JavaアプリケーションなのでMaven(pom.xml)を作成
    • VSTSでトリガーに対象のブランチが変更された時にMavenビルドを行う設定を実施
    • 後はVSTSでCIにチェックすればOK
    • Gitでpushされると自動的にビルドとテストが走り、結果をフィードバックする構成を実現
    • テストレポートとしてコードカバレッジも追加した
  • 自動テスト
    • JavaアプリケーションなのでJUnitでテストコードを記述
    • テストの勘所などは一旦置いておいて、不安となるところをテストした
    • Mavenプロジェクト構成にしておけばビルド時にtestタスクも勝手に走るので便利
  • 継続的デプロイ
    • 途中までで終わってしまった
    • CIでwarまでは作れたのだけれど、それをサーバーにデプロイするのにハマってしまった
    • どうもAzureポータルやVSTSのアカウント周りでうまく動かなかったみたい
    • 最初にアカウントを登録する代表者とOps担当が異なっていたことが割と致命的だったのかも。ここはMS側でもなにかしらの対策が欲しい
    • 他のチームもかなりハマっていたみたい
  • アプリ(サーバーサイド)
    • JSONライブラリを使用してGET,POST時にJSONを返却する仕組みはできた
    • データ永続化
      • SQLServerJDBCドライバ周りがうまく扱えず
      • DBからファイル管理へ変更...もAzureにデプロイしてうまくファイル操作できるか検証している時間がなかったのでメモリ上に保持することにした
        • どうやって期限切れのTodoを見つけるんですか...というのは内緒
    • メール送信機能は実装できず
  • アプリ(クライアントサイド)
    • 画面作成
    • Todo一覧の表示
    • Todo登録
    • Ajaxによるサーバーサイドとの連携もできたが、JSON解析から動的に反映するところまでは実装できなかった
    • そのため、JavaScriptでデモ用に実装してうまく繋いだ
  • その他
    • カンバンの採用
    • カンバンで作成したチケットからGitのブランチを作成してチケット駆動開発の採用

結果発表

アプリとしては完成までは行けなかったものの、採用したDevOpsプラクティスが評価されたのか、ありがたいことに優勝させて頂きました。

所感

今回Opsが居ないチームでしたが、結果的にDevOpsとしては失敗したのではないかと感じています。

Devはアジャイルな開発などで短いサイクルによる開発経験があります。しかし、Opsはゲームエンドと呼ばれているように短いサイクルでの構築作業に慣れていません。そのため、どうしても色々な観点でインフラ構成を詰め込みすぎてしまうのかなと感じました。

DevOpsはそこを解決する認識です。

他のチームのインフラ構成を見ていると、いかに我々のインフラが付け焼き刃なのかを痛感しました。だからこそシステム構成としてミニマムに作れたのです。

我々はDevOpsのプラクティスを僅かに多く実践できましたが、これらはあくまでDevの仕事でした。本来のOpsとしての仕事はほとんど盛り込めなかったと感じています。

ですから優勝はさせて頂いたものの、DevOpsとしては失敗であると感じたのです。

次はガッツリOpsの方とチームを組んで、エンドゲームにならないDevOpsハッカソンを経験してみたいと思います。