私の中の歴史愛好家の一面が、これまでの歴史上の有名なライバル関係を愛して止みません。ハートフィールド家 VS. マッコイ家、エリザベス1世 VS スコットランド女王メアリー、コーラ VS ペプシ、等々。恐らく、これらの偉大な争いが非常に魅力的にみえる原因は、私たちソフトウェアメーカーが毎日のように主導権争いをしているからだと考えられますが (当然、もっと平凡なレベルではありますが)、正にこれがきっかけとなって Bamboo 5 の大胆な新バージョンが誕生したのです。
継続的デリバリーの力を今までに無い形で活用して、チーム間の隔たりを克服するデプロイメント プロジェクトをここで紹介できる事を非常に喜ばしく思います。
ソフトウェアの開発と出荷に、緊張は付きものです。開発者たちは自分たちの作品が市場に出るのを心待ちにしている一方で、運用スタッフはプラットフォームを確実に安定させたいと考えています。製品マネージャーとマーケターはフィーチャーでいっぱいのリリースを非常に好む一方で、テスターは量よりも質を重視します。そして、誰もが自分の作業をステータス確認ミーティングによって中断される事無く、プロジェクトの進捗具合を完全に把握できればと願っています。
これらは全て、ツールが魔法の様に消し去る事のできない対立する文化的な作用です(ちょっとした組織内の緊張感は健全ですから、消えてなくなる必要も無いでしょう！)。しかし、ツールは緊張をほぐす事ができます。では、Bamboo 5 のデプロイメントプロジェクトが、いかにしてソフトウェア開発における激しいライバル関係を落ち着かせ、チーム間の協同作業をレベルアップさせたのかを見てみましょう。
ビルドとデプロイが一体となる
従来のツールは、どちらか一つだけなら上手くこなせます。「デプロイメントツール」では、デプロイされるアーティファクトがどこから来たものか、またそのレベルや品質に関してはほとんど注意が払われません。「継続的インテグレーションツール」においては、最新のビルドがテストに合格したら即座にデプロイする行為を継続的に行わない限り、リリースは後付けのようなものになってしまいます。事実を素直に受け入れるならば、これではほとんどのプロジェクトに適していない事が分かります。よって、チームは継続的にビルドとテストを繰り返し、E メール、スプレッドシート、そしてガムテープを頼りにビルドをリリースプロセスに結びつけてきました。
もう、このような事は必要ありません。Bamboo 5 では、今までと同様、ビルドとプロセス内テストの実行を引き続き行います。人間がアクセス可能な環境にビルドがデプロイされたら、それをリリースとしてフラッグする事で、それぞれの環境における成果を追跡できます。リリースはアーティファクトそのものに対するコンテナの役割を果たし、またコミット、JIRA 課題、どのビルドがアーティファクトの作成・テストを行ったか、リリースがどの環境にデプロイされ、それが誰によって行われたかといった膨大な関連情報としても機能します。
このビルドとデプロイの融合は、完全なる Bamboo 固有のものであり、製品チームのあらゆる人々に恩恵をもたらします。システム管理者とビルドエンジニアは、デベロッパーと QA が長年テストプロセスを自動化してきたのと同様に、デプロイメント作業を自動化できます。そればかりか、彼らはリリースにまつわるリスク査定を行うにあたって、アーティファクトがどのようにテストされたかを即座に確認できます。テスター、デベロッパーと製品マネージャーは運用の世界を眺める窓口を得た事で、バージョンが現在どの段階にあり、また販売促進の承認を受けたかを確認できるのです。
Bamboo のデプロイメントプロジェクトは、バージョンに関するチームの集約的知識を単一の真理の源に収めつつ、何がいつデプロイされるかに関する人的な決断能力を保持できる、強力な方法なのです。
視認性と効率性が一体となる
リリース間における変更点を理解しない事には、ロードマップに反する実行、リスクの最少化、あるいは緊急事態のトラブルシューティングを実現できません。しかし、スプレッドシートの更新やアーカイブされた E メールの検索といった終わりなきタスクには、本当にイライラさせられます。
Bamboo 5 は、JIRA 課題とビルドをただリンクするだけではありません。Bamboo を JIRA と接続する事で、あらゆる課題のロールアップ、そしてデプロイした二つのリリース間で実装された関連コミットを得る事ができます。Ops (運用) にとってこれは占いの水晶玉のようなものです。本番環境において何をデプロイしてサポートしなくてはならないかを予測するのが子供だましのように簡単になります。
近日中にアップデートされる JIRA-Bamboo プラグインが課題そのものの中でデプロイメント ステータスを表面化させるようになります。これからは、テスターはストーリーを検証できるか、それがどこにあるのかを見つけるのに余計な時間をかけずにすみます。(一度でもテスターをやった事がある人ならば、これがどれだけ素晴らしい事かお分かりでしょう。) サポートスタッフは、顧客が報告した欠陥の修正がリリース パイプラインのどこにあるのか、自信を持って彼らに伝える事ができます。プロジェクトマネージャーは、ある機能がリリース候補版のデプロイを果たしたかを即座に確認できます。
Dev (開発) と Ops (運用) が一体となる
これは重要です。一つ部屋の中にいる象と 500 ポンドのゴリラが、ラップで巻き付けられているようなものです。デベロッパーとシステム管理者は、その非友好的な関係が起因して非難される事があります(常に不当な非難という訳ではありませんが)。この両者が、長年の間善意を持ったマネジメントによってサイロ型の関係にされていた事を考慮するならば、自分たちの領域から足を踏み出し、協同作業を行う方法を再び学び直さなくてはならないとしても、何ら驚きはありません。
DevOps の動向にインスピレーションを受けた結果、私たちはデベロッパーとシステム管理者が協同する上で役立つ機能を Bamboo 5 に追加しました。デベロッパー・運用中心の情報を、デプロイメント プロジェクトとリリースを通じて相互交流させる事に加え、チームがリリース レディネスに関するコミュニケーションを図るのも簡単になりました。まず、バンドルに関してコメントできるという事は、チームがテスト中の発見事項、あるいはリリースにあたってどのようなインフラストラクチャ上の変更点が必要かに関してアイディアを共有できます。E メールとは違って、コメントは完全に民主的です。送信リストに含まれていたか否かに関わらず、誰もが参加でき、また後日参照するための公開記録も作成できます。次に、各バンドルには承認あるいはブロークンのフラグ立てが可能です。承認は QA からの承認を通信し、ブロークンフラグは運用に対してリリースが遅れる可能性を警告するため、デベロッパーが即座に対処できます。
スピードとコントロールが一体となる
何か一つを犠牲にしないで、他のものを得るのは極めて稀です。フェラーリの運転や、F-1 戦闘機の操縦はいい例です。そして、環境毎の許可のおかげで、Bamboo によるデプロイも同様です。ユーザーとグループに対する綿密な許可によって、デプロイメント作業のコンフィギュレーションと実行を誰が行うか、更には各環境におけるデプロイメント情報を誰が見れるかをコントロールできます。
これは明らかに、何十もの管理しなくてはならないプロジェクト、そして何百もの作業グループを抱えている大組織にとって、管理上の大きな成功となります。これが個別のチームメンバーにもたらす日々の影響力もまた、同様に大きなものになります。システム管理者は、他者によるサーバーへのアクセスを理由無く拒否する、コントロール観念に取り憑かれた人々としてしばしば誤解されます。また、デベロッパーは自分たちのマシーンで問題なかったから、本番環境でも当然問題が無いだろうと推測するカウボーイコーダーとして非難されます。これらはもちろんステレオタイプに過ぎませんが、Bamboo 5 の環境毎のデプロイ パーミッション設定は、優先事項の小競り合いを均衡させる上で役立ちます。
デベロッパーと QA は、本番環境とその他のデリケートな環境をロックダウンさせつつも、自分たちの環境にセルフサービス方式でデプロイできます。デベロッパーのスピードに関する障害は取り除かれ、運用がサービスしなくてはならないデプロイ要求は少なくなり、また安定性に執着したセキュリティオタクはぐっすり就寝できます。キャンプファイヤーの周りに全員を集結させて合唱させる事はできなくても、まずますの出だしではないでしょうか。
Bamboo 5 はデプロイメントにファーストクラスの処遇を与える、この種としては初のツールです。 私たちは本物の継続的デリバリーツールを作成しており、5.x シリーズのリリースでは更なる魅力をお届けする予定です。ご自分のインスタンスをアップグレードするか、無料のフルフィーチャー・トライアルを始めて Bamboo の違いを体験してみてください。
βプログラム参加者の皆さん、本当にありがとうございました！皆さんのフィードバックと提案は、本リリースを仕上げるにあたってとても役立ちました！
*本ブログは Atlassian Blogs の翻訳です。本文中の日時などは投稿当時のものですのでご了承ください。
*原文 : 2013 年 7 月 15 日 "Bamboo 5 Bridges the Dev-Ops Divide!"