優れたソフトウェアリリースの 3 つの要素

アーキテクチャ、チームワーク、それに自動化を追加して混ぜればできあがりです。

Dan Radigan Dan Radigan

一枚岩のソフトウェアリリースには、キャリアのどこかで遭遇します。つまり、扱いにくいバグや相互依存関係があり、チーム全体が 24 時間かかりきりにならなければならないようなソフトウェアリリースです。本番では複数のパッチが必要になることは言うまでもありません。

コードの出荷、つまりリリースは、ソフトウェア開発者のアジリティの優れた指標です。リリースプロセスがスムーズではないと、計画、コーディング、テストをすばやく行おうとするあらゆる努力が水の泡となります。アジャイルにリリースするためには、自動デプロイは重要であり、コード製作者と運用者が開発の初期段階からコミュニケーションをとり、継続的インテグレーションを実践し、不具合に即座に対応することも大事です。

コードをリリース可能な状態で維持できることは、アジャイル開発の特長です。 準備ができたと判断した瞬間にコードを出荷できなければ、リーン計画や反復型開発の意味がまったくありません。 

優れたソフトウェアリリースは、モジュールアーキテクチャから始まる

In any software program, it's best to release easily and often. A team can make release a natural part of their agile culture by building (or refactor towards) a modular architecture. Rather than have one large application (like the monolith mentioned above), early on in the program modularize it into several pieces. Group similar features into smaller applications or components, and have clear API contracts between each of the applications and components. Those APIs can be tested automatically with every build to ensure compatibility and reduce risk in the software release.

モジュールアーキテクチャでは、ソフトウェアスタック全体を「ビッグバン」式でリリースする必要がありません。API 規約により、コンポーネントの更新が簡単になり、バージョン間の互換性を確保できます。つまりモジュール式リリースの方が可動部が少なく、リリースがシンプルになります。

優れたソフトウェアリリースは、良好な関係によって実現される

Software development is seldom done in a vacuum. Indeed, great software development involves the entire team from product management to operations. For example, the operations team is a key partner in delivering software to production since they help the software reach end users.

開発チームは運用チームに次のテクニックを伝えることができます。

  • 各リリースの部品表を明確にしましょう。運用チームと開発チームで、リリースのコンテキストレベルが同じであるとは限りません。
  • そのリリースにおいて解決された各課題について課題管理システムおよびソースコード管理システムへのリンクを用意し、デプロイメント中に問題が発生した場合に運用チームが同レベルのコンテキストを把握できるようにします。
  • 開発環境からステージング環境にコードを移行した段階で課題が表面化することもあります。本番でも問題が起こる可能性があるため、このような課題には別途対応しましょう。
  • デプロイメント時には不具合が発生するものです。問題をスムーズに解決できるよう、運用チームにエスカレーションパスを明確に伝えておきましょう。

運用チームは開発チームに次のような提案を行うことができます。

  • 本番で問題が発生した場合、時間をとって原因と解決策を探りましょう。将来の問題を回避 (あるいは適切に対応) するためです。
  • 設定の混乱を防止するために、設定データを本番環境からステージングおよびデプロイメント環境に移行しましょう。

コードを開発からステージング、本番へと移行すると同時に、重要な設定およびユーザーデータは本番からステージング、開発へと逆方向に移行します。双方向の関係を持たせることで、開発環境に本番環境を緊密に反映させることができます。これはリリース日のバグや不測の事態の減少につながります。

Great software releases | Atlassian Agile Coach

優れたソフトウェアリリースは、簡単にプッシュできる

自動化!自動化!自動化!

リリース文化を改善する最適な方法は、リリースの自動化です。リリースをまだ自動化していないのであれば、まずステージング環境へのリリースを自動化しましょう。そのシンプルさを体験すれば、自然と本番展開の自動化へと進むでしょう。

リリースが困難な場合は、リリース頻度を上げるようにしましょう。ステージングへのリリースでもかまいません。開発チームにリリースの問題点を感じてもらうことが、もっと簡単にする (そして自動化する) ためのイノベーションのきっかけとなります。

Automated testing and continuous integration are key disciplines that power great releases. Ensure that build times and testing times are as short as possible, and remember that builds that are easy to validate are easier to release. That's because the validation cycle more closely follows the team. 

優れたソフトウェアリリースはすばらしい!

コードをリリース可能な状態で維持できることは、アジャイル開発の特長です。

私たちの方法

SaaS の特性から、小規模リリースを頻繁に行うのが最も管理しやすいという結論に至りました。ダウンロード型の製品では、開発チーム、運用チーム、ビルドエンジニアリングチームの間での緊密な協力が大きな意味を持っています。これらのグループが連携してリリースを自動化し、その後の製品の変更に合わせて自動化を積極的に適応させます。アトラシアンでは、たくさんのチームが成功したマスターのビルドを自動的にテスト環境にデプロイしています。 リリースをステージングに昇格、または顧客にリリースすべき時がくると、ボタンを押して自動デプロイを開始します。 

ソフトウェア開発者にとって、リリースはイノベーションサイクルのハイライトであるべきです。作成したコードを顧客がどのように使用しているかを観察し、フィードバックを得ることができます。リリースを日常化すれば、本番環境でのコード展開が容易になり、自分のコードが使用されているという充実感が得られます!