ガイド：小規模チーム向けのソフトウェアリリース管理

リリース管理プロセスの形式化（ある場合）

一部のチーム構成、特にスタートアップに見られる構成では、製品の新しいバージョンをリリースするときにサポートを提供するDevOpsもインフラストラクチャエンジニアもいません。

さらに、正式なプロセスが定義されている大規模な官僚企業とは異なり、スタートアップのCTOまたはソフトウェア開発チームの責任者は、ソフトウェアリリース管理プロセスの複雑さに気付いていないことがよくあります。 社内の数人の開発者は、プロセスの複雑な詳細を知っているかもしれませんが、全員ではありません。 この知識が完全に文書化されていないと、混乱を招く可能性があると思います。

この記事では、特に開発者の観点から、リリースプロセスを形式化する方法に関するヒントをいくつか提供しようと思います。

ソフトウェアリリースチェックリストを入力してください

Atul Gawandeの著書、 Checklist Manifestoにあるように、いくつかの操作のチェックリストのアイデアに精通しているかもしれません。 正式なリリースプロセス（ソフトウェア開発の世界の他の多くのタスクと同様）は、開発者にこのプロトコルを実装する機会を提供すると思います。 リリースプロセスのチェックリストは、共有ドキュメントに保存する必要があります。できれば、共同WikiまたはGoogleドライブのスプレッドシートの形式で保存してください。

この重要なドキュメントをチームと共有し、編集権限を付与することで、すべてのメンバーが正式に定義されたリリースプロセスにアクセスできます。 これにより、プロセスがどのように機能するかを理解できます。 さらに、他のチームメンバーとの話し合いに続いて、チームが時々それを改善できるようにします。 これにより、透明性がもたらされ、チーム全体がリリース中に何が起こっているのか、どのステップが完了したのか、誰が行ったのかをリアルタイムで確認できるようになります。

このスプレッドシートを見ると、利害関係者は、手順の結果に基づいて、「GO」と「NOGO」を決定できます。 たとえば、テスト環境でストレステストが失敗した場合、プロジェクトマネージャーは、イベントに基づいて本番リリースを中止することを決定する可能性があります。

基盤として使用するための推奨手順

このセクションでは、リリースプロセス用の独自のチェックリストを作成するために使用できるいくつかの手順を提案します。 これらの手順の一部は必須ではありません。 アプリはそれぞれ異なり、組織ごとに動作も異なるため、ワークフローに適した変更を自由に行ってください。

1.リリースブランチを作成します

Gitワークフローの概念、または以前のブログ投稿で説明されているトピックであるリリースブランチの概念に精通している可能性があります。

理想的には、少なくとも3つのブランチが必要です。

• マスター：これは、実稼働環境にあるものの現在の状態を反映する必要があります。 マスターでのすべての新しいコミットは、新しいリリースのみを構成する必要があります。
• 開発：このブランチには、完成した（そしてテストされた）今後の機能が含まれている必要があります。 機能ごとに個別のブランチを作成し、機能の準備ができたらそれをマージして開発するのが一般的です。
• リリース：リリースブランチは、本番環境に送信する準備ができているコミットのコレクションに加えて、リリースに関連するいくつかの追加のマイナーなバグ修正です。

リリースが完了したら、リリースブランチを削除する必要があることに注意してください。したがって、これらのブランチは、常に同じであるmasterやdevelopとは異なり、常に作成および破棄されます。

新しいリリースブランチを作成するには、gitターミナルのdevelopブランチから次のように入力します。

$ git checkout -b release/xyz

上記で定義したような命名規則を使用して、必要に応じてxyzをmajor.minor.patchバージョン番号に置き換えると便利です（これは、チーム内で定義し、それに固執する必要があるポリシーです）。

また、いくつかのバグ修正をリリースブランチにコーディングする場合は、それらをマージして開発に戻すことを忘れないでください。 リリースブランチの主な目的は、本番環境に移行した後のアプリの動作のプレビュースナップショットを作成することです。

2.バンプバージョン

次のステップは、リリースブランチのバージョン番号をバンプ（変更または増加）することです。

AndroidManifest.xml / package.json / pom.xml /またはアプリのバージョンがプロジェクト（YMMV）に保存されている場所を開き、バージョン番号を更新してから、現在のリリースブランチに変更をコミットする必要があります。

2つの理由から、バージョン番号を更新することが重要です。

まず、各バージョンで導入された機能を追跡およびマッピングできます。次に、トラブルシューティングを行う必要がある場合やサポートについて連絡する必要がある場合に、使用しているバージョンを認識できます。 モバイルアプリを構築している場合、このステップで更新するバージョン番号は通常、ユーザーエンド、[バージョン情報]セクション、 GooglePlayまたはAppleApp Storeに表示されます。このステップは、環境に依存する更新を行う良い機会でもあります。 -構成ファイル（ただし、別のリポジトリに保存することをお勧めします）。たとえば、本番データベースへのブランチポイントを作成したり、ビルドプロセスで必要なその他の調整を行ったりします。

最後に、リリースブランチをオリジンにプッシュして、他の開発者が利用できるようにすることをお勧めします。

$ git push -u origin release/xyz

3a。 リリースブランチをマスターにマージしてタグ付けします

本番環境ではマスターブランチのみをデプロイする必要があるため、このステップでは、リリースブランチをマスターにマージする必要があります。

 $ git checkout master $ git merge --no-ff release/xyz $ git push

--no-ffフラグはオプションですが、早送り手法を使用してマージを完了できる場合でも、新しいコミットオブジェクトを強制的に作成するために使用することをお勧めします。

次に、マスターブランチでリリースにタグを付けます。

$ git tag -a xyz -m 'description of new version, features or fixes included'

タグは、履歴のこの特定のポイントをgitリポジトリに保持しているため便利です。後で戻って、特定のタグから別のブランチを再作成できます。

3b。 プルリクエストを使用してリリースブランチをマージします

よく使用されるもう1つの方法は、プルリクエストを使用してリリースブランチをマスターにマージすることです。

このアプローチには多くの利点があります。 チームがさまざまなリリース関連の問題について話し合うために使用できる、コラボレーション用の新しいスペースが作成されます。 この時点で、コードレビュープロセスを組み込むためのゲートを追加すると同時に、導入されるコードを監視し、変更の可能性について話し合うための目玉を増やすことができます。

プルリクエストをワークフローに実装できるツールには、GitHub、Bitbucket、GitLab（後者ではリクエストをマージ）があります。 これらのツールでは、gitコマンドを手動で入力するのではなく、Webインターフェイスを使用してソースブランチ（ release ）と宛先ブランチ（ master ）を設定してから、1人以上のレビュー担当者を追加します。これらの新しい変更についてインラインコメントを書き込んだり、改善を提案したりすることができます。

すべてのレビュー担当者がプルリクエストを承認した後、UIのボタンを押すことで、変更をマスターに自動的にマージできます。

4.マスターを実稼働環境にデプロイします

この段階では、アプリをデプロイする前に、チームのテスターに​​スモークテスト（これは別のチェックリストで定義できます）を実行させることをお勧めします。 マスターブランチを別のテスト環境にデプロイすることをお勧めします。 その後、テスターはいくつかの基本的なアクションを実行して、最新のビルドでのマージ後に問題が発生していないことを確認できます。 スモークテストの実施方法はこの記事の範囲を超えていますが、ウェブ上でそれに関する多くの資料を見つけることができます。 スモークテストの結果は、リリースチェックリスト/スプレッドシートに統合して、問題が発生したことを文書化することができます。

この時点で、変更をデプロイして公開する準備が整いました。 先に進み、マスターブランチをデプロイします。 この手順は、使用しているインフラストラクチャスタックによって異なります。 これには、Amazon EC2インスタンスに接続してアプリをアップロードするか、Herokuリモートにプッシュするか、ssh経由でVPSに接続して新しいバージョンをコピーするか、その他のプロセスが含まれる場合があります。

アプリをアップロードしたら、アプリが正常にデプロイされ、期待どおりに機能することを確認します。

5.リリースブランチの開発と削除にマージバック

これでリリースはほぼ完了しました。リリースブランチをdevelopにマージし、後者のバージョン番号を更新して、行われたすべてのバグ修正をメインの開発ブランチに転送する必要があります。

 $ git checkout develop $ git merge release/xyz

次に、リリースブランチを削除します。

$ git branch -d release/xyz

6.変更ログの生成

プロジェクトのルートにCHANGELOG.md（または同等のもの）という名前のファイルがあり、バグ修正、新機能、既知の問題、およびリリースノートの形式でのその他の関連情報。 これは、プロジェクトの各リリース（またはバージョン）間でどのような変更が加えられたかをユーザーや寄稿者が確認するのに非常に役立ちます。

変更ログエントリには、日付、バージョン番号、およびリリースに関するいくつかのメモが含まれています。 エントリは新しいものから順に保持する必要があります。 これが私が使用している簡単なテンプレートで、プロジェクトに適応させることができます。

 <app's name or component released> <version xyz> | <date> <developer's name in charge of release> | <developer's email> Features: * <ticket/issue number>: <ticket/issue summary> (<link to issue tracker>) * ... Bugs fixed: * <ticket/issue number>: <ticket/issue summary> (<link to issue tracker>) * ... Enhancements: * <ticket/issue number>: <ticket/issue summary> (<link to issue tracker>) * ... Optional: known issues plus other release notes.

さらに、このステップは、gitログをトラバースしてchangelogエントリを自動的に生成する基本的なスクリプトをコーディングするか、次のような同じことを行うツールを使用することで、完全に自動化できます。

• スカイワインダーによるGithubChangelogGenerator、
• fojuthによるReadmeGen
• github-変更、lalitkapoorによる

ただし、得られる自動化の程度は、コミットメッセージ形式の厳密さに正比例することに注意してください。 チームとコミットメッセージの特定の形式について合意することは常に良い習慣だと思います。 コミットメッセージのスタイルに関するガイドラインに従うことで、メッセージの解析が容易になり、変更ログの生成を自動化できる可能性が高くなります。

7.利害関係者とのコミュニケーション

これは通常、次のいくつかを行う場所です。

• 新しいリリースが完了したことを、内部メッセージングツール（例：Slack）を介してチームに知らせます。 リリース関連のイベントを伝達することのみを目的として、新しいチャネル（つまり、 ＃releases ）を作成することをお勧めします。 Slackチャネルにフックを追加して、アクションが実行された後にメッセージを投稿するのは簡単です。
• または、変更ログへのリンクまたは変更ログファイルを添付した電子メールを関係者に送信します。
• ブログ投稿（アプリや製品のブログがある場合）またはツイートを作成します。

組織の性質に応じて、より多くのアクションを実行できます。 重要なことは、製品の新しいバージョンが利用可能であることを伝えることを忘れないことです。

8.課題追跡システムのグルーミング

リリースが実行された後、現在本番環境にあるバグ修正または機能を追跡するために、チケットの一部のステータスを更新する必要があります。 通常、これにはいくつかのタグの変更が含まれます（小さなプロジェクトでは、リリース保留タグを使用します。これは、リリースの完了後に削除します）。

新しいバージョンごとにマイルストーンを使用する場合は、ステータスを更新するか、完了としてマークする必要があります。 一部の課題追跡システムでは、リリースを計画してスプリントに合わせたり、バグがリリースをブロックしているかどうかを追跡したり、その他の有用な情報を入手したりすることもできます。

それはすべて、ツールの使用方法によって異なります。 課題追跡システムの情報を更新するタスクは、リリースチェックリストに含める必要があることを指摘したいと思います。

リリースプロセスの自動化について

読者は、上記で概説した変更ログのステップとは別に、前述のステップの多くも自動化できることに気付いたかもしれません。

リリースプロセスの一部を自動化する機能は大きなメリットであり、多くの時間を節約できます。 スクリプトを作成するか、個々のステップを自動化して継続的デリバリーの目標に向けて取り組む方法を理解することをお勧めします。 継続的デリバリーにより、リスクを軽減し、コストを削減し、開発者がリリースの管理に費やす時間を削減できます。 その結果、より頻繁にリリースし、開発に割り当てられた時間の点でより生産的になることができます。

DevOps企業の聖杯は、リリースプロセスを自動的にトリガーするボタンを押す（またはコマンドを実行する）ことで新しいバージョンを起動できることです。さらに良いのは、ソフトウェアの新しいバージョンを次の場所でリリースするシステムです。指定された時間。 もちろん、多くのテストプロセスも自動化する必要があるため、これを実現するのは困難ですが、不可能ではありません。

ベストプラクティスを採用する

このセクションでは、リリースプロセスをスムーズにするため、または問題が発生した場合の安全対策を講じるために、便利だと思ったいくつかの推奨プラクティスについて説明します。

リリースを実行するのに最適な日を見つける

私は通常、木曜日の正午から営業終了まで、作業中のアプリをリリースします。

月曜日から金曜日まで作業する場合は、金曜日に起動することはお勧めできません。 リリース後に何かが故障した場合、月曜日まで修正する時間がありません（週末に仕事をしたい場合を除く）。 そのため、木曜日にリリースを行う方が便利です。金曜日には、デプロイ後に新しいバージョンを監視したり、問題を修正したり、ロールバックしたりできるからです。

Webアプリを管理している場合に言及するもう一つの重要なことは、ユーザーの大多数がいるタイムゾーンを知ることです。 何かが失敗した場合の潜在的な損傷を最小限に抑えるために、トラフィックの少ない期間にリリースの時間を計る必要があります。 ユーザーベースが全世界に広がっている場合、これは難しい場合がありますが、とにかく、調査を行って最適な時期を決定する必要があります。

新しいリリースの前にデータベースをバックアップする

DBの定期的なバックアップをスケジュールしていない場合は、リリースプロセスにステップを追加して、リリースを開始する前にバックアップを実行することを強くお勧めします。

段階的なロールアウト

出版社が新機能のリリースを発表したときに、その機能が携帯電話で利用できるようになるまでに数日、場合によっては数週間かかるのはなぜだろうと思ったことはありませんか。 これは、多くの企業が段階的な展開を使用しているためです。

Facebookはこれを長い間行ってきました。 ユーザーの5〜10％で新機能をテストし、ユーザーベースの100％に達するまで徐々に増やしていきます。 段階的な展開フェーズでは、ユーザーのフィードバックとクラッシュレポートを注意深く確認する必要があります。 この情報を使用して、すべてのユーザーに影響を与える前に、リリースを延期したり、エラーを修正したりできます。

Androidのデベロッパーコンソールには、Androidアプリの段階的なロールアウトを実装する優れたツールがあります。

継続的インテグレーション

継続的インテグレーションは、多くの理由で採用する価値のあるプラクティスです。 まず、間違いを早期に検出できるため、リリースの成功率が高まります。 次に、前述のように、継続的デリバリーと完全自動化を実装する前の最初の論理的なステップです。

マーティンファウラーは、継続的インテグレーションの大きな支持者です。 彼は、このプラクティスを使用するときにリリースプロセスに追加できる膨大な量の利点について説明しています。 これは大きなトピックであり、それに関する本やブログ投稿がたくさんあります。ここで言及するのは、それがあなたの業務にはるかに自信を与えると信じているからです。 CIを使用することの多くの利点の中には、リスクの軽減、機能しているものと機能していないものを認識するための可視性の向上、バグの早期検出、展開の頻度の増加などがあります。

CIを実装するための出発点は、「継続的インテグレーションサーバー」をセットアップすることです。 試してみるのに最適なツールは、CruiseControl、Bamboo、Jenkins、Travisです。

エグジットルード：それはすべてうまくいくでしょう

積極的に、私たちは皆、私たちが果たす役割を擁護します残念ながら、あなたを途中で送る時が来ます私たちはそれをすべて見てきました、信頼の焚き火、痛みの鉄砲水それは本当に問題ではありません、心配しないでください、それはすべてうまくいく

エグジットルード、ザキラーズ

まとめると、アプリの複雑さ、ユーザーベース、組織の規模に関係なく、アプリのリリースプロセスを明確に定義することが非常に重要だと思います。

そうでない場合は、このガイドやその他のガイドを使用して、いくつかの基本的な手順について考え始め、チームとブレインストーミングして最初のドラフトを作成することをお勧めします。 次のリリースで試してから、繰り返してください。 最終的には、独自のリリースプロセスを構築することになります。

その後、プロセスの一部を自動化する方法について考え始めます。 改善できる分野について考えてください。 小さな最適化を組み込むことにより、リリース時間を短縮する方法を探ります。 自動化はあなたの究極の目標でなければなりません。 ただし、最初からそれを計画しないでください。そうしないと、このような大きな飛躍を試みて失敗することになります。 すべてのプロセスと同様に、徐々に改善することをお勧めします。

アプリの新しいバージョンを起動するために使用する他のトリックやガイドラインはありますか？ もしそうなら、私に知らせてください。 私はDevOpsの世界から来たわけではありません。私はたまたま非常に組織化され構造化された開発者ですが、多くのベテランと比較すると、この点ではまだ初心者です。追加するもの。