バックエンド
ガイド：小規模チーム向けのソフトウェアリリース管理
リリース管理プロセスの形式化（ある場合）
一部のチーム構成、特にスタートアップに見られる構成では、製品の新しいバージョンをリリースするときにサポートを提供するDevOpsもインフラストラクチャエンジニアもいません。
さらに、正式なプロセスが定義されている大規模な官僚企業とは異なり、スタートアップのCTOまたはソフトウェア開発チームの責任者は、ソフトウェアリリース管理プロセスの複雑さに気付いていないことがよくあります。社内の数人の開発者は、プロセスの複雑な詳細を知っているかもしれませんが、全員ではありません。この知識がない場合 徹底的に文書化 、混乱を招く可能性があると思います。
この記事では、特に開発者の観点から、リリースプロセスを形式化する方法に関するヒントをいくつか紹介します。
ソフトウェアリリースチェックリストを入力してください
いくつかの操作のチェックリストのアイデアに精通しているかもしれません。 チェックリストマニフェスト 、アトゥール・ガワンデの本。正式なリリースプロセス（ソフトウェア開発の世界の他の多くのタスクと同様）は、開発者にこのプロトコルを実装する機会を提供すると思います。リリースプロセスのチェックリストは、共有ドキュメントに保存する必要があります。できれば、共同WikiまたはGoogleドライブのスプレッドシートの形式で保存してください。
この重要なドキュメントをチームと共有し、編集権限を付与することで、すべてのメンバーが正式に定義されたリリースプロセスにアクセスできます。これにより、プロセスがどのように機能するかを理解できます。さらに、他のチームメンバーとの話し合いに続いて、チームが時々それを改善できるようにします。これにより透明性がもたらされ、チーム全体がリリース中に何が起こっているのか、どのステップが完了したのか、誰が行ったのかをリアルタイムで確認できるようになります。
このスプレッドシートを見ると、利害関係者は、手順の結果に基づいて、「GO」と「NOGO」を決定できます。たとえば、テスト環境でストレステストが失敗した場合、プロジェクトマネージャーは、イベントに基づいて、製品リリースを中止することを決定する場合があります。
基盤として使用するための推奨手順
このセクションでは、リリースプロセスの独自のチェックリストを作成するために使用できるいくつかの手順を提案します。これらのステップのいくつか 必須ではありません 。アプリはそれぞれ異なり、組織ごとに動作も異なるため、ワークフローに適した変更を自由に行ってください。
1.リリースブランチを作成します
あなたはの概念に精通している可能性があります Gitワークフロー 、またはリリースブランチのアイデアで、説明されているトピック 以前のブログ投稿で 。
AWS認定を行う方法
理想的には、少なくとも3つのブランチが必要です。
- 主人 ：これは、実稼働環境にあるものの現在の状態を反映している必要があります。すべての新しいコミット 主人 新しいリリースのみで構成する必要があります。
- 発展させる ：このブランチには、完成した（そしてテストされた）今後の機能が含まれている必要があります。機能ごとに個別のブランチを作成し、それをにマージするのが一般的です。 発展させる 機能の準備ができたとき。
- リリース ： リリース ブランチは、本番環境に送信する準備ができているコミットのコレクションに加えて、リリースに関連するいくつかの追加のマイナーなバグ修正です。
に注意してください リリース リリースが完了したらブランチを削除する必要があるため、これらのブランチは常に作成および破棄されます。 主人 または 発展させる 、常に同じです。
新しいを作成するために リリース ブランチから 発展させる gitターミナルでブランチを入力し、次のように入力します。
$ git checkout -b release/x.y.z
上記で定義したような命名規則を使用して、必要に応じてx.y.zをmajor.minor.patchバージョン番号に置き換えると便利です（これは、チーム内で定義し、それに固執する必要があるポリシーです）。
また、いくつかのバグ修正をリリースブランチにコーディングする場合は、それらをマージして戻すことを忘れないでください。 発展させる 。リリースブランチの主な目的は、本番環境に移行した後のアプリの動作のプレビュースナップショットを作成することです。
2.バンプバージョン
次のステップは、のバージョン番号をバンプ（変更または増加）することです。 リリース ブランチ。
AndroidManifest.xml / package.json / pom.xml /またはアプリのバージョンがプロジェクト（YMMV）に保存されている場所を開き、バージョン番号を更新してから、現在のバージョンに変更をコミットする必要があります リリース ブランチ。
2つの理由から、バージョン番号を更新することが重要です。
まず、各バージョンで導入された機能を追跡およびマッピングできます。次に、トラブルシューティングを行う必要がある場合、またはサポートについて連絡する必要がある場合に、使用しているバージョンを認識できます。モバイルアプリを構築している場合、このステップで更新するバージョン番号は通常、ユーザー側の 約 セクションまたは グーグルプレイ または Apple App Store この手順は、本番データベースへの分岐点の作成や、ビルドプロセスで必要なその他の調整など、環境に依存する構成ファイルを更新する良い機会でもあります（ただし、これらのファイルは別のリポジトリに保持することをお勧めします）。 。
最後に、を押すことをお勧めします リリース オリジンに分岐するため、他の開発者が利用できます。
$ git push -u origin release/x.y.z
3a。リリースブランチをマスターにマージし、タグを付けます
だけ 主人 ブランチは本番環境にデプロイする必要があるため、このステップでは、 リリース に分岐 主人 。
グラフィックデザインとビジュアルデザイン
$ git checkout master $ git merge --no-ff release/x.y.z $ git push --no-ffフラグはオプションですが、早送りの手法を使用してマージを完了できる場合でも、新しいコミットオブジェクトを強制的に作成するために使用することをお勧めします。
次に、リリースにタグを付ける時が来ました 主人 ブランチ：
$ git tag -a x.y.z -m 'description of new version, features or fixes included'
タグは、履歴のこの特定のポイントをgitリポジトリに保持しているので便利です。後で戻って、特定のタグから別のブランチを再作成できます。
3b。プルリクエストを使用してリリースブランチをマージします
よく使用されるもう1つの方法は、 プルリクエスト マージするには リリース に分岐 主人 。
このアプローチには多くの利点があります。チームがさまざまなリリース関連の問題について話し合うために使用できる、コラボレーション用の新しいスペースが作成されます。この時点で、コードレビュープロセスを組み込むためのゲートを追加すると同時に、導入されるコードを監視し、潜在的な変更について話し合うための目玉を増やす良い機会です。
プルリクエストをワークフローに実装できるツールには、次のようなものがあります。 GitHub 、 Bitbucket そして GitLab （後者ではリクエストをマージします）。これらのツールでは、gitコマンドを手動で入力するのではなく、ウェブインターフェースを使用してソースブランチを設定します（ リリース ）および宛先ブランチ（ 主人 ）、次に1人以上のレビュー担当者を追加します。レビュー担当者は全員、これらの新しい変更についてインラインコメントを書き込んだり、改善を提案したりできます。
すべてのレビュー担当者がプルリクエストを承認した後、変更をに自動的にマージできます 主人 UIのボタンを押します。
4.マスターを実稼働環境にデプロイします
この段階で、チームのテスターに次のことを行わせることをお勧めします。 スモークテスト （これは別のチェックリストで定義できます）アプリをデプロイする前に。良い提案は、 主人 別のテスト環境に分岐します。その後、テスターはいくつかの基本的なアクションを実行して、最新のビルドでのマージ後に問題が発生していないことを確認できます。スモークテストの実施方法はこの記事の範囲を超えていますが、ウェブ上でそれに関する多くの資料を見つけることができます。スモークテストの結果は、リリースチェックリスト/スプレッドシートに統合して、問題が発生したことをすべて文書化できます。
この時点で、変更をデプロイして公開する準備が整いました。先に進んで展開します 主人 ブランチ。この手順は、使用しているインフラストラクチャスタックによって異なります。これには、Amazon EC2インスタンスに接続してアプリをアップロードするか、Herokuリモートにプッシュするか、sshを介してVPSに接続して新しいバージョンをコピーするか、その他のプロセスが含まれる場合があります。
アプリをアップロードしたら、アプリが正常にデプロイされ、期待どおりに機能することを確認します。
5.マージして元に戻す 発展させる そして削除 リリース ブランチ
これでリリースはほぼ完了しました。マージする必要があります リリース に分岐 発展させる 、後者のバージョン番号を更新し、行われたすべてのバグ修正をメインの開発ブランチに転送するには：
$ git checkout develop $ git merge release/x.y.z 今度は削除する時が来ました リリース ブランチ：
$ git branch -d release/x.y.z
グーグルグラスの使い方
6.変更ログの生成
プロジェクトのルートにCHANGELOG.md（または同等のもの）という名前のファイルがあり、バグ修正、新機能など、それに含まれるすべてのものを文書化するために、新しいリリースがあるたびに新しいエントリを追加する必要があります。既知の問題、およびリリースノートの形式のその他の関連情報。これは ユーザーと寄稿者にとって本当に便利です プロジェクトの各リリース（またはバージョン）間でどのような変更が加えられたかを確認します。
変更ログエントリには、日付、バージョン番号、およびリリースに関するいくつかのメモが含まれています。エントリは新しいものから順に保持する必要があります。これが私が使用している簡単なテンプレートで、プロジェクトに適応させることができます。
| | Features: * : () * ... Bugs fixed: * : () * ... Enhancements: * : () * ... Optional: known issues plus other release notes. さらに、このステップは、gitログをトラバースして変更ログエントリを自動的に生成する基本的なスクリプトをコーディングするか、次のような同じことを行うツールを使用することで、完全に自動化できます。
- Github変更ログジェネレーター 、スカイワインダーによって、
- ReadmeGen fojuthによって
- github-変更 、lalitkapoorによる
ただし、得られる自動化の程度は、コミットメッセージ形式の厳密さに正比例することに注意してください。チームとコミットメッセージの特定の形式について合意することは常に良い習慣だと思います。コミットメッセージのスタイルに関するガイドラインに従うことで、メッセージの解析が容易になり、変更ログの生成を自動化できる可能性が高くなります。
7.利害関係者とのコミュニケーション
これは、通常、次のいくつかを行う場所です。
- 新しいリリースが完了したことを、内部メッセージングツール（例：Slack）を介してチームに知らせます。新しいチャネルを作成することをお勧めします（例： #releases ）リリース関連のイベントを伝達することのみを目的としています。 Slackチャネルにフックを追加して、アクションが実行された後にメッセージを投稿するのは簡単です。
- または、変更ログへのリンクまたは変更ログファイルを添付した電子メールを関係者に送信します。
- ブログ投稿（アプリや製品のブログがある場合）またはツイートを作成します。
組織の性質に応じて、さらに多くのアクションを実行できます。重要なことは、製品の新しいバージョンが利用可能であることを伝えることを忘れないことです。
8.課題トラッカーのグルーミング
リリースが実行された後、現在生産中のバグ修正または機能を追跡するために、チケットのいくつかのステータスを更新する必要があるでしょう。通常、これにはいくつかのタグの変更が含まれます（小さなプロジェクトの場合は リリース保留中 タグ。リリースが完了した後に削除します）。
新しいバージョンごとにマイルストーンを使用する場合は、ステータスを更新するか、完了としてマークする必要があります。一部の課題追跡システムでは、リリースを計画してスプリントに合わせたり、バグがリリースをブロックしているかどうかを追跡したり、その他の有用な情報を提供したりすることもできます。
それはすべて、ツールの使用方法によって異なります。課題追跡システムの情報を更新するタスクは、リリースチェックリストに含める必要があることを指摘したいと思います。
リリースプロセスの自動化について
読者は、上記で概説した変更ログのステップとは別に、前述のステップの多くも自動化できることに気付いたかもしれません。
リリースプロセスの一部を自動化する機能は大きなメリットであり、多くの時間を節約できます。スクリプトを作成するか、個々のステップを自動化してから、 継続的デリバリー ゴール。継続的デリバリーにより、リスクを軽減し、コストを削減し、開発者がリリースの管理に費やす時間を削減できます。その結果、より頻繁にリリースし、開発に割り当てられた時間の点でより生産的になることができます。
の聖杯 DevOps企業 リリースプロセスを自動的にトリガーするボタンを押す（またはコマンドを実行する）ことで新しいバージョンを起動できるようにすることです。さらに良いのは、指定された時間にソフトウェアの新しいバージョンをリリースするシステムです。もちろん、これは多くのテストプロセスも自動化する必要があるため、達成するのは困難ですが、不可能ではありません。
ベストプラクティスの採用
このセクションでは、リリースプロセスをスムーズにするため、または問題が発生した場合の安全対策を講じるために、便利だと思ったいくつかの推奨プラクティスについて説明します。
リリースを実行するのに最適な日を見つける
私は通常、木曜日の正午から営業終了まで、作業中のアプリをリリースします。
月曜日から金曜日まで働く場合、金曜日にローンチするのは良い考えではありません。リリース後に問題が発生した場合、月曜日まで修正する時間がありません（週末に仕事をしたい場合を除く）。そのため、木曜日にリリースを行う方が便利です。金曜日には、デプロイ後に新しいバージョンを監視したり、問題を修正したり、ロールバックを行ったりする必要があるためです。
Webアプリを管理している場合に言及するもう一つの重要なことは、ユーザーの大多数がいるタイムゾーンを知ることです。何かが失敗した場合の潜在的な損傷を最小限に抑えるために、トラフィックの少ない期間にリリースの時間を計る必要があります。ユーザーベースが全世界に広がっている場合、これは難しい場合がありますが、とにかく、調査を行って最適な時期を決定する必要があります。
新しいリリースの前にデータベースをバックアップする
DBの定期的なバックアップがスケジュールされていない場合は、リリースプロセスにステップを追加して、リリースを開始する前にバックアップを実行することを強くお勧めします。
段階的なロールアウト
サイト運営者が新機能のリリースを発表したときに、その機能がスマートフォンで利用できるようになるまでに数日、場合によっては数週間かかるのはなぜだろうと思ったことはありませんか。これは、多くの企業が段階的な展開を使用しているためです。
Facebookはこれを長い間行ってきました。ユーザーの5％または10％で新機能をテストし、ユーザーベースの100％に達するまで徐々に増やしていきます。段階的な展開フェーズでは、ユーザーのフィードバックとクラッシュレポートを詳しく調べる必要があります。この情報を使用して、すべてのユーザーに影響を与える前に、リリースを延期したり、エラーを修正したりできます。
Androidのデベロッパーコンソールには、Androidアプリの段階的なロールアウトを実装する優れたツールがあります。
継続的インテグレーション
継続的インテグレーションは、受け入れる価値のあるプラクティスです 多くの理由で 。まず、間違いを早期に検出できるため、リリースの成功率が高まります。次に、前述のように継続的デリバリーと完全自動化を実装する前の最初の論理的なステップです。
マーティンファウラーはの大きな支持者です 継続的インテグレーション 。彼は、このプラクティスを使用するときにリリースプロセスに追加できる膨大な量の利点について説明しています。これは大きなトピックであり、それに関する本やブログ投稿がたくさんあります。ここで言及するのは、それがあなたの業務にはるかに自信を与えると信じているからです。 CIを使用することの多くの利点の中には、リスクの軽減、機能しているものと機能していないものを認識するための可視性の向上、バグの早期検出、展開の頻度の増加などがあります。
CIを実装するための出発点は、「継続的インテグレーションサーバー」をセットアップすることです。試してみるとよいツールは、CruiseControl、Bamboo、Jenkins、Travisです。
エグジットルード：それはすべてうまくいくでしょう
積極的に、私たちは皆、私たちが果たす役割を擁護します 残念ながら、あなたを途中で送る時が来ます 私たちはそれをすべて見てきました、信頼の焚き火、痛みの鉄砲水 それは本当に問題ではありません、心配しないでください、それはすべてうまくいくでしょう
エグジットルード、ザキラーズ
まとめると、アプリの複雑さ、ユーザーベース、組織の規模に関係なく、アプリのリリースプロセスを明確に定義することが非常に重要だと思います。
javascriptは非同期呼び出しが終了するのを待ちます
そうでない場合は、このガイドや他のガイドを使用して、いくつかの基本的な手順について考え始め、チームとブレインストーミングして最初のドラフトを作成することをお勧めします。次のリリースで試してから、繰り返してください。最終的には、独自のリリースプロセスを構築することになります。
その後、方法を考え始めます プロセスの一部を自動化する 。改善できる領域について考えてください。小さな最適化を組み込むことにより、リリース時間を短縮する方法を探ります。自動化はあなたの究極の目標でなければなりません。ただし、最初からそれを計画しないでください。そうしないと、そのような大きな飛躍を試みて失敗します。すべてのプロセスと同様に、徐々に改善することをお勧めします。
アプリの新しいバージョンを起動するために使用する他のトリックやガイドラインはありますか？もしそうなら、私に知らせてください。私はから来ません DevOps 世界では、私はたまたま非常に組織化され構造化された開発者ですが、多くのベテランと比較して、私はまだこの点で初心者です。何か追加があれば、コメントするか、私に連絡してください。
