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

2016年を振り返る

お仕事

前半はBlue-Green Deploymentの導入やっていた。技術的には去年やっていたことの焼き直しだったので、モチベーション的には苦しいものがあったが、何とかかたちになるアウトプットを出せたと思う。

twitter.com

転職してから丸三年になりますが、同じお客様を担当して四年目に突入することになりました。SIの世界では結構異例なことですが、ありがたいことだと思います。

その一方で、春からは社内の他の案件の支援も担当することになった。来年も頑張る。

コミュニティー活動

www.slideshare.net

www.slideshare.net

www.slideshare.net

www.slideshare.net

主催
  • BDD in Action読書会

アウトプットを一段上のレベルに出そうとして、講演では色々チャレンジした。その結果として消化不良気味になったものもあるが、次につなげていきたい。

趣味

  • miwa「miwa “ballad collection” tour 2016 ~graduation~」3公演
  • いきものがかり 「超いきものまつり2016 地元でSHOW!! 〜海老名でしょー!!!〜 / 〜厚木でしょー!」 3公演

まとめ

もう若さまかさでどうこうする年齢でもないですが、一日一日を健康を大事にして、明るく楽しく生きていたい。

Bitbucket PipelinesとBambooのブランチモデルの違いに見るデプロイ戦略の構造

このエントリーは、Atlassian User Group Tokyo Advent Calendar 2016 - Qiitaの23日目エントリーです。

qiita.com

2016年10月に開催されたアトラシアンサミットソースコードホスティングサービスBitbucket Cloud継続的インテグレーション(CI)によるビルド・デプロイを統合した新サービス、Bitbucket pipelinesのサービスインが発表されました。

Bitbucket Pipelinesは、Bitbucket上で管理されているソースコードにビルド設定を記述したbitbucket-pipelines.yml()をコミットすると、Bitbucketへのソースコードのpushをトリガーとしてビルド及びデプロイを実行するというサービスで、Travis CIを始めとするGitHubに統合されたCIホスティングサービスと同様のサービス形態になっています。また、本年12月一杯までは無料で使用できます(2017年1月以降は1セント/1分の予定)。

Bitbucket Pipelinesの特徴としては、以下の四点が挙げられます

  • Bitbucket Cloudとの統合
  • DSL(bitbucket-pipelines.yml)でのビルド記述
  • Dockerベースでのビルド環境
  • プルリクエストベースでのビルドフロー

このエントリーでは、同じくアトラシアン社のオンプレミスでのCIパッケージであるBambooと比較した場合に大きな特徴となる、プルリクエストベースでのビルドフローについて、Bambooとの比較をしながら、述べていきます。このエントリーで試用したサンプルはBitbucket上で公開しています

プルリクエストベースでのビルドフロー

Bitbucket Pipelinesでは、bitbucket-pipelines.yml上での記述により、ブランチごとにビルドの設定をカスタマイズすることができます。

Bitbucket Pipelinsでデプロイを行うには、デプロイの対象となるブランチに対して、プルリクエストを作成します。例えばbitbucket-piplelines.yml上で、masterブランチをビルドした際に本番環境へデプロイを行うように記述されている場合、本番環境へのデプロイを行う場合には、masterブランチに対して、プルリクエストを作成します。

f:id:setoazusa:20161223213713p:plain

f:id:setoazusa:20161223220216p:plain

これは、GitHubに統合するかたちでのCIサービスで広く採用されているワークフローと同様なっています。これに対してBambooのデプロイは、それぞれのブランチのビルドを起点としてリリースを作成し、そのリリース内の成果物(artifafct)を各環境にデプロイするワークフローとなっています。

プルリクエストでのデプロイの特徴

プルリクエストを中心としたワークフローベースのデプロイの特徴としては、やはりワークフローが簡潔となることが挙げられます。どのような手順を踏めばデプロイされるかということが、「masterブランチにブランチをマージすれば本番環境にデプロイ」されるというように明快になります。また、ワークフローが単純になることのメリットとして、チャットを運用のワークフローに組み込む、ChatOpsへの親和性も高くなります。

これに対するデメリットは、ブランチのビルド設定とデプロイのワークフローを結びつけたことにより、一つの環境にデプロイされるのは特定のブランチの最新ビルドとなることがあげられます。これに対し、BambooのようにCIのビルドからリリースを作成するデプロイの場合は、任意ブランチの任意ビルドがデプロイ可能です。

今のプロジェクトで、releaseのブランチがリリース準備の作業中の時に、本番環境で緊急に修正を要する障害が発生した場合のデリバリーのワークフローの検討を行ったりもしたのですが、こういう場合はやはりBambooのようなリリースとブランチが疎結合になっているモデルのほうが都合が良い、と考えます。

また、リリース時に問題が発生し、一個前のバージョンに戻す、いわゆる「切り戻し」を行う場合は、プルリクエストベースのデプロイの場合は、

  • リリース内容をrevertするコミットを作成して再度プルリクエストを作成する
  • リリースブランチをリリース前のリビジョンでハードリセットする
  • immutable infrastructureにして一個前のインフラ構成に戻す

のいずれかの手順を踏むことになります。

これに対して、Bambooのようなリリース内の成果物をデプロイする場合は、CIサーバー上で一個前のバージョンのリリースをデプロイすることによって、切り戻しを行う事ができます。

また、複数モジュールからなるシステムを構築する際、モジュールが親モジュール(いわゆる「共通モジュール」)と子モジュールに別れている場合に、Bambooではブランチごとに独立してビルドの依存関係を持たせてビルドチェーンを構築することができますが、Bitbucket Pipelinesではそのような機能を有していません。

まとめ

このようにBitbucket PipeliesのようなプルリクエストベースのワークフローとBambooのようなリリースベースのワークフローを比較した場合に、プルリクエストベースでのデプロイの特徴としてあげられるのは、パイプラインがバージョン管理システム(VCS)のブランチと密結合になるかわりに、身軽さを得たワークフローだということです。このようにデプロイのワークフローについての設計思想がBambooと根幹から違うため、Bitbucket PipelinesはBambooの代替にそのままでなるものではなく、実際Bambooにも新機能の追加は活発に行われていますので、ワークフローに対して求められる厳格さに応じて、しばらくはBitbucket PipelinesとBambooの棲み分けが続くと考えられます。

参考

私といきものがかり

このエントリーは、いきものがかり Advent Calendar 2016 - Adventarの20日目エントリーです。

www.adventar.org

さて明日12/21*1は、2016年8月と9月にいきものがかりの地元と海老名と厚木で行われた屋外ライブ「超いきものまつり2016 地元でSHOW!!」のブルーレイ発売日ですね。みなさんこのエントリーを読んだらブルーレイをポチるのですよ?

えっ、DVDプレイヤーしかない?いえいえ、世界で一番可愛い32歳こと吉岡聖恵さんのお姿を堪能するにはブルーレイじゃないと駄目です、プレイヤーも一緒にカートにいれてくださいw

...という振りはさておき、いきものがかりの魅力と言えばライブです。ステージを所狭しと走り回るパフォーマンスに、楽曲だけでなくMCでも観客を魅了する姿。いきものがかりの公演って週末公演や地方公演だと開演から終演まで3時間くらいかかるのが*2通常です。で、そのかなりの時間がMCなのですが、自分も他のアーティストのライブに行くようになって気づいたのですが、アーティストがみんなMCに多くの時間を割くわけではないらしいのですね。後MCでリード役をつとめるリーダー水野良樹さんの自虐ネタのトークも見物です。

さて、このアドベントカレンダーの作成者である (id:noobow34)の私といきものがかりの6年間 - ぬぼろぐにならって、私のいきものがかりライブ参戦歴を振り返ってみたいと思います。ちなみに私のものぐさな性格を反映して参戦歴を洗い出すのに、Twitterの過去つぶやきやらgoogleカレンダーやらmixiのつぶやきやら日記やらカレンダーやら掘り起こして大捜索になりましたが、色々と昔のことも思い出してきますね。

2009年

2010年

このころからチケットの取りやすさ等の関連で地方公演が増えてますね。ちなみに沖縄公演はファイナルの予定だったのですが、チケット二重発券の振り替え公演の影響で幻のファイナルになったことは尾を引き、いきものがかりの公演のファイナルに立ち会うのは2016年まで待つことになります。ローチケ許すまじ

2011年

この年のいきものがかりと言えばハマスタ公演ですが、広島でのファンクラスライブの時に私、仕事の関係で「夜公演終了(広島)→最終の新幹線で大阪→一泊→翌朝の始発新幹線で東京へ→会社のロッカーで背広に着替えて出社」というのをやっているのですが...何をやりたかったのでしょうね、私。

2012年

twitter.com

www.instagram.com

遠征はいいぞ。

2013年

この時期仕事が大炎上している中転職活動もしつつ、miwaもふくめると4ヶ月でライブ6本行っているのですが...我ながらこのパワーはどこから出てくるのでしょうね。

2014年

ライブツアーなし

2015年

この年はこれでしょうね。人生の運を使い切ったと思った。*3

twitter.com

2016年

いきものがかり10周年イヤー。開演前から降り続く本降りの雨のためずぶ濡れ、泥まみれの最悪のコンディションになった海老名初日が思い出深いです。

twitter.com

2017年

まだまだ続くよ!

*1:担当日基準

*2:平日の公演の場合は観客の帰りの便を考えて、若干つめる

*3:この時のライブは座席券が当日発券のため、席が決まるのは当日

Gebでインフラをテストする。

Geb Advent Calendar 2016 - Qiitaの12日目エントリーです。

qiita.com

先日の「JJUG CCC 2016 Fall」で「実録Blue-Green Deployment導入記」というテーマで発表しましたが、その中でインフラ観点でのシステムテストにGebを活用した事例の紹介をしました。

インフラのテストの観点の特徴としてあげられるのは、最終的な動作の確認をアプリケーション層に依存することがあげられます。

  • 設定ファイルの項目の確認
  • アプリケーションのプロセスが起動しているかの確認
  • ヘルスチェックのURLにアクセスして行う疎通の確認
  • サーバーおよびネットワーク機器間の疎通の確認

という観点まではServerspec等を用いたテストが可能ですが、それより上位レベルの観点はデプロイしたアプリケーション上の動作で確認することになります。

このような場合、インフラ側のテスト担当者が

  • アプリケーション側の機能ドキュメント、テストケース一覧
  • 過去のインフラ観点でのテストケース
  • インフラ側のテスト担当者の勘

などを参照して、テストケースを作成します。

ですが、

  • アプリケーションの規模
  • サーバーやネットワーク構成
  • 外部との連携先

などの構成が複雑になるにつれ、インフラのテスト担当者がアプリケーション観点でテストケースを作成することへのハードルはあがってきます。

また、この事例で取り上げたシステムの場合、システムが

  • 「エンドユーザーからのアクセスを受け付けるモードか」(主系)
  • 「動作確認のためのアクセスを受け付けるモードか」(副系)

の二つのモードをもっており、その結果として

  • Blueサーバーが主系の場合のBlueサーバーへのアクセス
  • Blueサーバーが主系の場合のGreenサーバーへのアクセス
  • Greenサーバーが主系の場合のGreenサーバーへのアクセス
  • Greenサーバーが主系の場合のBlueサーバーへのアクセス

で、一つのテストパターンについて、都合四通りのテストの組み合わせを実施することになりました。

そこで、この事例ではアプリケーションの観点から見たインフラのテストについて、全面的にアプリケーションの開発チームがGebによって作成したエンドツーエンドのテストを使用することになりました。エンドユーザー側から見た、アプリケーションの機能および外部サービスへの連携について、構築した環境上でGebによるエンドツーテストを実行し、その結果を確認することで、インフラ観点でのシステムテストを行うわけです。

このことによって、

  • テストケースの作成コストの削減
  • テストケースの網羅度、信頼性向上
  • 組み合わせでテストを実行する場合の、実行コスト削減

という効果を得ることができました。

エンドツーエンドのテストを実装する場合、その効果はアプリケーションを開発する側のアプリケーションの修正に関わるコストの範囲内で語られがちです。しかし、エンドツーエンドの自動テストである程度の網羅性を担保することによって、インフラ側のテストの効率や精度の向上にも寄与することができる、というのが今回の事例で得られた知見です。

テスト自動化あれこれ

ソフトウェアテスト Advent Calendar 2016 - Qiitaの9日目エントリーです。

qiita.com

エラーが「自動的に」増殖するのがDevOps

継続的デリバリーの核心は、フィードバックのサイクルを素早く回すことにありますが、それはユニットテストカバレッジが十分になければ不可能です。 A/Bテスト、オートスケール、カナリヤテスト、Blue-Green Deploymentなど、DevOpsを推進する上での各種プラクティスは、いずれも、プロダクトの品質が安定していることを前提としています。品質が安定していない状態でリリースサイクルを早く回してもバグが素早くデリバリーされるだけです。

サービス開発は、開発者だけで行うものでなく、プロダクトオーナー、QAエンジニア、インフラエンジニア、運用エンジニア、リモート開発チームなど、多数のステークホルダーが協調して行うものです。チーム相互の信頼をもたらすために必要なのは安定したプロダクトの品質であり、継続的インテグレーション(CI)を軸としたデリバリーのワークフローの確立のためには、自動化されたテストが足場として必要です。

迅速なサービス開発の手助けにならない自動化テスト

翻って現場に目を向けたときに、最近複数の現場で見聞きするのは、

  • 必要とするミドルウェアや連携先サービスとの関係でテストがモックだらけになり、ユニットテストの可読性や保守性があがらない
  • それを補完すべくエンドツーエンドのテストに取り組んでいるが、テストケースが増えてきてメンテナンスコストや実行コスト(時間)が増大している

というものです。各種パブリッククラウド上でのサービス構築に代表されるように、システムを構築し、テストを実装するときに依存するサービスやミドルウェアが増えたこと、そしてマイクロサービスアーキテクチャーがその流れを加速しています。

それに対して、テストをはじめとして開発の方法論はいわゆる三層アーキテクチャーにいまだに最適化されており、そのことが自動テストの普及の妨げになっています。

テスト自動化ピラミッドとサービステスト

Mike Cohnは書籍「Succeeding with Agile」の中で、テスト自動化の戦略をレイヤーを「UI」「Service」「Unit」の3つに分類し、「テスト自動化ピラミッド」と命名しています。「Unit」の層はいわゆるユニットテストに相当し、「UI」の層はエンドツーエンドのテストに相当します。このピラミッドの特徴は「Service」の層にあって、アプリケーションのインターフェースに対するテストを、UIを迂回して実行することです。

Succeeding with Agile: Software Development Using Scrum (Addison-Wesley Signature Series (Cohn))

Succeeding with Agile: Software Development Using Scrum (Addison-Wesley Signature Series (Cohn))

f:id:setoazusa:20161208200716p:plain

*1

このピラミッド自体は一種の概念モデルですが、Sam Newmanは書籍「マイクロサービスアーキテクチャ」の中でこのモデルに着目しています。

マイクロサービスアーキテクチャ

マイクロサービスアーキテクチャ

マイクロサービスアーキテクチャーにおけるサービステストとは、外部のサービス呼び出しをモック化した上で、個々のサービスの機能に対して、UIを迂回してテストを実行します。このことにより、ユニットテストよりも広い範囲をカバーするテストを、エンドツーエンドのテストよりも安定かつ高速に実行できることを目指しています。

f:id:setoazusa:20161208200648p:plain

*2

まとめ

方向性としては、システムのコンポーネント間の関係、規模など、複雑度が増大するに伴い、自動化されたテスト、手動で行うテスト双方とも、レイヤーの分割を細かくして、テストのどこのレイヤーでどの品質を担保していくかを事前に設計した上で開発に望んでいくということになります。我が国では業界の生い立ちや歴史的背景から、ソフトウェア開発の職種とソフトウェアテストの職種の相互交流はまだはじまったばかりですが、開発エンジニアとテストエンジニアが共通の言語で会話しながら、システムの品質に対する責任を相互で分担できる未来が来ることを望みます。

*1:Mike Cohn(2010)「Successiding with Agile」312ページより

*2:Sam Newman著(2015)・佐藤直生監訳「マイクロサービスアーキテクチャ」160ページより

JJUG CCC 2016 FallでBlue-Green Deploymentの導入について発表しました #jjug_ccc

2016/12/3に開催されたJJUG CCC 2016 Fallで「実録Blue-Green Deployment導入記」というテーマで発表しました。

講演中でもちょっと触れたとおり、案件での事例に特化したセッションですので、皆様の現場で一般的に使えるノウハウではないかもしれません。

ですが、セッションで挙げた三つのテーマである

  • サイトの切替にDNSを使う場合の接続元クライアントの挙動の制御
  • データベースの取扱い
  • Blue Greenの稼働系を切り替える場合の切り替え手順の考慮

については、サービス無停止でリリースを行う上で、どこでも考慮が必要になるポイントだと考えています。

質疑応答で、「Blue-Greenの切替時に処理途中で処理する稼働系が切り替わるようなケースがないのか?」という質問がありましたが、この事についてうまく回答ができなかったので、この場で補足をいたします。

例えばGreenサーバーに新しいバージョンをデプロイしてBlueサーバーからGreenサーバーに稼働するシステムを切り替える場合、Greenサーバーではセッション中で説明した通り、テスト用のグローバルIPアドレスを使って動作確認済み(スライド内で「副系」と読んでいるもの)ですので、Blueサーバーへのリクエストが途中でGreenサーバーに乗りかわるのは問題ありません。問題となるのは、Greenサーバーへのリクエストが途中でBlueサーバーに移行するようなシーケンスが発生すると、機能的に一個前のバージョンとなりますので、例えば呼び出し先のAPIがないなどの問題が発生します。

このことに対応するために、切替元となるBlueサーバーの随時バッチが起動するサーバー(スライド中の「データ連携サーバー」と呼んでいるもの)のプロセスを切替時にいったん停止する手順を入れています。(発表スライド中の以下のページなります。)このことによって、切替時にGreenサーバー(切替先)へのリクエストが途中でBlueサーバー(切替元)に乗り変わることを防いでいます。

スライドの最後で「日本のDevOpsはSIがリードする」なんていう大風呂敷を広げましたが、これについて。各種ソーシャルメディアで現場に対するネガティブな面を振りまくのは言論の自由の範疇ですが、最近、何か事をなし得たというエントリーに対して、揚げ足を取ったり話の腰を折ったりするコメントが多すぎます。ストレスの捌け口というのも必要でしょうし、キャリアの浅さやスキルの至らなさで自分のやりたいことが実現できない現場にいる方もいらっしゃるでしょうが、もうすぐ40代の自分たちの世代は、現場と業界をどうやればよりよくできているかが求められる役割なので、それが後の世代への責任ではないのかと。自分が2年前のJJUG CCCで言った「ミッションを共有するする仲間が集うコミュニティーで、プログラマーが一人一人知恵を持ち寄り、議論し、勇気づけるときに、世界はかわる、そう思う。」を、自分はまだ取り下げるつもりはないです。

JJUG CCCが終わって感想ですが、ここ2年ばかりかかり切りだった案件の成果を世に発表できたので、今は安堵しているところです。

最後になりますが、

  • 発表の機会をいただいたJJUGのみなさま
  • スライドのレビューをいただいたプロジェクト関係者
  • 発表リハサールに立ち会っていただいた弊社同僚

以上のみなさま、ありがとうございました!

JJUG CCC 2016 FallでBlue-Green Deploymentの導入事例について登壇します。

2016/12/3にベルサール新宿グランド コンファレンスセンターで開催されるJJUG CCC 2016 fallで、10:00からG+H会場で「実録Blue-Green Deployment 導入記」で登壇します。

www.java-users.jp

JJUG CCC 2014 Fallのセッション「私がTDDできないのはどう考えてもお前らが悪い!~エンタープライズJava開発でのTDD適用の勘所~」で事例として取り上げたサービスのその後についてです。ユーザーの拡大に伴いサービス無停止でのリリースに取り組む事になり、TDDの推進をミッションとしてプロジェクトに参画した発表者はデプロイの自動化、そしてインフラ運用を担当するようになりました。

疎結合アーキテクチャーのシステムを、サービス無停止でリリースできるように作り替える上でサブシステム相互の連携をどう作り込むのか、DNSロードバランサーの挙動にあわせて稼働系システムの連携をどう作り込むか、そしてその中でテストの自動化がどう役割を果たすか。最終的にBlue-Green Deploymentになるまで1年以上に及び、今なお改善をつづけているインフラ運用の実態について発表します。

構成は「GSLB(Global Site Load Balancing)によるサイト切替」「Blue-Green Deploymentにおけるデータベースの扱い」「Blue-Green Deploymentにおける実装及び運用上の留意点」になる予定です。朝早い時間帯ですが、Blue-Green Deploymentの導入について興味がある方は是非お越しください。

同時上映のid:syobochim さんと @_Dr_ASAさんによる「SIerもはじめる、わたしたちのDevOps」もお楽しみに!