サイト内検索

閉じる閉じる

サイト内検索

閉じる

ITアーキテクトコラム

  1. コラム
  2. ITアーキテクトコラム
  3. [DevOps連載]第3回 価値を繰り返し提供するために

[DevOps連載]第3回 価値を繰り返し提供するために

2017/07/04

友野 敬大友野 敬大

  • Facebook
  • Twitter
  • google+
  • はてなブックマーク
  • DepOps

システム開発を進める中で、「デリバリー」という言葉を初めて聞く、という方
は少ないと思います。プロジェクト達成指標であるQCDの一つとして有名ですね。
プロジェクト管理の観点では「納期」と訳されることが多いですが、DevOpsにお
いては価値を提供するプロセスを指します。

第3回目の今回は、DevOpsの「デリバリー」フェーズに着目したコンテンツをご
提供します。 コラムではデリバリーフェーズとひとまとめにしていますが、実際
はソース管理~ビルド~テスト~プロビジョニング~デプロイという一連の流れ
が対象です。

Webサービスを利用した継続的インテグレーションのすすめ

前回コラムの通り、DevOpsの文脈では、ユーザーストーリーの実現がまさに
ユーザーへの価値提供に繋がるのだと言えます。
しかし、新しい価値の実現・検証を行うと同時に、これまでできたことが変わら
ずできることも保証しなければなりません。1つや2つの機能であれば、実際に
動かして試してみることもできますが、うまくツールを利用する方が賢明です。

DevOpsでは、まずデリバリーフェーズを自動化する流れ、すなわちデリバリー
パイプラインの構築を検討します。

ご存知の方も多いと思いますが、「継続的インテグレーション(※)」(以降、CI
とします)が最初のステップとなります。デリバリーパイプラインを構成する要
素の一つであり、ウォーターフォール手法でも段階的リリースや保守開発のシー
ンで、デグレード防止目的などに利用可能です。CIを実現するために最低限必要
な要素は下記の3つです。
1.あらゆる成果物をバージョン管理する
2.ビルド・テストを自動化する
3.上記要素を組み合わせて流れを制御する

バージョン管理と流れの制御については、GitBucketやJenkinsなどのOSSで自社
環境に構築するのが主流かと思います。一方で、昨今ではGitHub、AWS
CodeBuild/CodePipelineなどのWebサービスを利用するという選択肢もあり、
特にCI環境未構築や管理者不在という現場では、後者をおすすめします。CI環境
自体は顧客に価値を提供するわけではないので、環境を維持するために多くのリ
ソースを充てるのは非効率的ということもありますが、フルマネージドのため、
スケール問題から解放されることが大きな理由です。上記のWebサービスは従量
課金制かつ安価で、シンプルな構成であればすぐに構築できるので、まずは試し
てみるのもよいと思います。

テスト自動化は"End to End"で

CIを利用して夜間や変更の度にビルドするだけでも一定の効果はありますが、テ
スト自動化を実践することでその効果を一層高めることができます。ただし、ど
のテストを自動化するのかについてはさまざまな議論があるでしょう。テスト駆
動開発を採用しユニットテストからしっかりコードを書いている現場であれば特
に言うことはありませんが、そうでない場合はEnd to Endのテストケースを自動
化するのが効果的です。前回コラムで紹介したユーザーストーリーの3Cの一つ、
「Confirmation」の実現手段になり得ます。

一般的にユーザーストーリーが満たされているかどうかは、ユーザーが見える形
で検証する必要があります。例えば、「登録画面を操作して処理結果が登録完了
画面に表示される」という流れがあるとすれば、これをテストします。ユーザー
ストーリーには複数の完了条件(受入基準)が設定されることが多いので、それ
ぞれのテストケースを自動化してCIに組み込めば、安定して開発を続けることが
できるでしょう。

クラウドネイティブのデプロイ

合意したユーザーストーリーを満たし、リリースタイミングを迎えたらサーバー
にアプリケーションをデプロイします。しかし、リリースする内容に実験的なも
のが含まれる場合、すぐに戻したくなるかもしれません。アプリケーションだけ
切り戻して事が済めばよいのですが、サーバーの設定も併せて変更している場合
は、ロールバック作業はより複雑になります。 DevOpsでは「Infrastructure as
Code」「Blue-Greenデプロイ」というプラクティスを利用して、これらの問題
を解決します。大きな流れとして、下記の通りです。
1.サーバー群の設定をコード化してバージョン管理する
2.リリースの度に環境を再構築する
3.アプリケーションをデプロイして最終確認を行う
4.結果が合格であれば、ロードバランサーを切り替えてユーザーに公開する

これらの流れは、従来のサーバー調達プロセスでは時間的にも金銭的にも難しい
ですが、クラウドサービスが広く普及したからこそ実現できるようになりました。
DevOpsにおける『価値を継続して提供し続ける』ことは、まさにインフラのコー
ド化クラウドサービスの進化、テストの自動化技術に支えられているのです。
今回は触れていませんが、Dockerに代表される仮想コンテナの活用事例も増えて
きており、周辺技術の進化は留まることがありません。日頃から新しいツールの
情報をウォッチして、快適な開発を目指しましょう。

次回は「フィードバック」についてです。

 

  • ※ 継続的インテグレーション:開発者が自分のコード変更を定期的にセントラルリポジトリにマージし、その後に自動化されたビルドとテストを実行するソフトウェア開発の手法

  • 記載されている製品名は各社の商標または登録商標です

著者プロフィール

友野 敬大

友野 敬大

開発本部 金融ソリューション第1部 金融テクノロジーソリューショングループ

当社のクラウドサービス「寄付金クラウド」をはじめ、金融機関向け・エネルギー企業向けの複数のクラウドサービス案件に参画し、基盤構築からアプリケーション開発(Java)まで幅広く従事してきました。これらの経験から、プロダクト(ひいては組織)の全体最適化に興味を持ち、その一つであるDevOpsを推進し、お客様に提案しています。先日、娘が生まれ、溺愛しています。

資料請求・お問い合わせはこちら

インターネットからの資料請求

インターネットでのお問い合わせ

お電話でのお問い合わせ

営業本部03-6757-7211

受付時間 9:00~17:30(土日祝日を除く)