[レポート]DevOps on AWS: Deep Dive on Continuous Delivery and the AWS Developer Tools #AWSSummit
丹内です。掲題のセッションに出席したのでをレポートします。
DevOpsとは
- ソフトウェア配布モデルは変化しており、今日の競争力の源泉である
- スマフォ、時計、車など様々な形式がある。ソフトウェアのデプロイ先は常に変わっている
- 必要なのは、開発フロー、テスト、デプロイの各種ツール
プロセスについて考える
- ソフトウェアのリリースプロセスは以下の4ステージ
- ソース作成(コードのチェックイン)
- ビルド(実行可能な形式にする)
- テスト
- 運用(デプロイ)
- リリースレベルのプロセスは、どこまで自動化するかで以下のような呼び方がある。今日の焦点は継続的デリバリ。
- 継続的インテグレーションはコードのチェックインからテストまで自動化
- 継続的デリバリは運用の直前まで自動化
- 継続的デプロイメントは運用まで自動化
- 継続的デリバリは、リリースプロセスの自動化、生産性改善、バグへの素早い対処、アップデート配信の高速化をもたらす
- amazonの開発を振り返ると、2001年はモノリシックなアプリ/チームだったのが、2009年にはマイクロサービス/2ピザチーム
- しかしまだ改善、すなわち開発からデプロイまでが早くなる余地がある。
- 2009年の調査の結果は、「我々はただ待っているだけだった」。
- 誰かかがコーディングするのを
- 誰かがビルドするのを
- 誰かがテスト環境にデプロイするのを
- 誰かが本番環境にデプロイするのを
- アクション自体は数分だが、アクション間を待つところで数日かかっている
- そこで自動化するツール=パイプラインを構築した。チェックインから運用まで、アクションとtランジションを自動化。高速・安全になる他に、一貫製や標準化、プロセスが実装という形で明らかになるという利益がある
- 現在もamazonはこの方法で現在も成果を上げ続けている。継続的デリバリによって、開発者がより幸せになる。
codepipeline
- 継続的デリバリサービス。プロセスの可視化を行うGUIベースツール
- パイプラインはステージとアクションとトランジションを持つ。並列/逐次アクションも可能。
- CodepipelineがGitHubをポーリングして変更を取得し、アーティファクトとしてS3に格納
- Jenkinsプラグインがcodepipelineをポーリングしてジョブを承認してアーティファクトを取得テスト。完了をcodepipelineに報告する
- そしてawsデプロイツールと連携してデプロイ。
- codepipelineは様々なパートナーと連携している。AWS OpsWorksのサポートをセッションの5時間前に開始!
- ビルドではlambda functionの呼び出しも可能。
リリースパイプライン構築のデモ
- pipelineを作成し、GH連携でリポジトリとブランチを設定
- Solano CIというBuildプロセスを設定、BetaステージデプロイでEBを選択しapplicationとenvironmentを設定
- 作成直後、自動で初回実行される
- Betaステージに追加設定。UIテストアクションとしてGhost Inspector UIテストを追加。逐次実行。
- productionステージも追加。CodeDeploy。
- アクションが失敗するとトランジションが遷移しない
ビルドステージ
- 言語によってbuildがあるか変わる。Dockeイメージ作成でもビルドとなるインタプリタ言語ではコードをデプロイするだけ
- テストは、動作以外にも、組織に応じたフォーマットチェックやセキュリティテストも実施する。
- デプロイはAWSのサービスと連動。CodeDeployはappspec.ymlに動作を記述。
本番環境へのローンチ
- 顧客、インフラ、ビジネスへの影響を考慮する必要がある。追跡する必要もある。告知する必要がある
- カスタムアクションでAWS Codepipelineを拡張する
- モバイルテスト
- チケット更新
- リソースのプロビジョニング
- ダッシュボードの更新
- 通知の送信
- セキュリティスキャン
- つまりリリースに伴う定形作業をLambdaで行う
- bit.ly/AWSCodeStarterKitでスターターキットを配布しているので使ってみて欲しい。
まとめ
AWSのツールを組み合わせて、開発からリリースまでの定形作業をまとめることができます。 CodePipelineが東京に来る日が待ち遠しいです。