GitLab でソフトウェア パッチをリリースする方法

GitLab では、ソフトウェア修正を手動と自動の XNUMX つの方法で処理します。 この記事を読んで、gitlab.com への自動デプロイメントを介して重要なアップデートを作成して配信するリリース マネージャーの仕事と、ユーザーが自分のインストールで作業するためのパッチについて学びましょう。

スマートウォッチにリマインダーを設定することをお勧めします。毎月 22 日に、施設で GitLab を使用しているユーザーは、製品の現在のバージョンの更新を確認できます。 毎月のリリースには新機能や既存機能の開発が含まれており、多くの場合、ツールやマージに対するコミュニティのリクエストの最終結果が示されます。

しかし、実践が示すように、ソフトウェア開発に欠陥がないことはほとんどありません。 バグやセキュリティの脆弱性が発見されると、配信チームのリリース マネージャーがユーザーのインストール用のパッチを作成します。 Gitlab.com は CD プロセス中に更新されます。 GitLab の CD 機能との混同を避けるために、この CD プロセスを自動デプロイメントと呼びます。 このプロセスには、ユーザー、顧客、社内開発チームから送信されたプル リクエストからの提案を組み込むことができるため、パッチのリリースという退屈な問題は XNUMX つのまったく異なる方法で解決されます。

«開発者が作成したものはすべて、GitLab.com に展開する前に毎日すべての環境にデプロイされていることを確認します。」と説明する マリン・ジャンコフキ, インフラストラクチャ部門シニアテクニカルマネージャー。 」インストールのリリースは、gitlab.com デプロイメントのスナップショットと考えてください。そのために、ユーザーがそれを使用してインストールにインストールできるように、パッケージを作成する別の手順が追加されました。'。

バグや脆弱性に関係なく、gitlab.com の顧客は公開後すぐに修正を受け取ることができます。これは自動化された CD プロセスの利点です。 独自にインストールしたユーザー向けのパッチは、リリース マネージャーによる個別の準備が必要です。

配信チームは、リリースの作成に関わるプロセスのほとんどを自動化して、コストを削減することに懸命に取り組んでいます。 MTTP (本番までの平均時間、つまり本番に費やされる時間)、開発者によるマージリクエストの処理から gitlab.com でのデプロイメントまでの期間。

«配達チームの目標は、会社として確実に迅速に行動できるようにすること、少なくとも配達担当者の作業を迅速化できるようにすることです。?とマリンは言います。

gitlab.com の顧客とそのインストールのユーザーの両方が、サイクル タイムを短縮し、デプロイメントを高速化するというデリバリー チームの取り組みから恩恵を受けています。 この記事では、これら XNUMX つの方法の類似点と相違点について説明します。 問題また、配信チームがオンサイトで実行しているユーザー向けにパッチを準備する方法と、自動デプロイメントを使用して gitlab.com を最新の状態に保つ方法についても説明します。

リリースマネージャーは何をするのですか?

毎月のチームメンバー リリースマネージャーの役​​割を譲渡する リリースの間に発生する可能性のあるパッチやセキュリティ リリースを含む、ユーザーの施設へのリリース。 また、自動化された継続的な展開への会社の移行を主導する責任もあります。

自己インストール リリースと gitlab.com リリースは同様のワークフローを使用しますが、異なるタイミングで実行されます、と Marin 氏は説明します。

何よりもまず、リリース マネージャーは、リリース タイプに関係なく、アプリケーションが gitlab.com で起動された瞬間から GitLab が利用可能で安全であることを保証します。これには、顧客のインフラストラクチャで同じ問題が発生しないようにすることも含まれます。自分自身の能力。

GitLab でバグまたは脆弱性が修正済みとしてマークされると、リリース マネージャーは、それがユーザーのインストール環境のパッチまたはセキュリティ アップデートに含まれるかどうかを評価する必要があります。 バグまたは脆弱性がアップデートに値すると判断した場合、準備作業が始まります。

リリース マネージャーは、修正を準備するかどうか、またはいつ展開するかを決定する必要があります。これは状況のコンテキストに大きく依存します。」一方で、機械は人間ほどコンテキストを管理するのが得意ではありません。」とマリンは言います。

すべては修正の問題です

パッチとは何ですか?なぜパッチが必要なのでしょうか?

リリース マネージャーは、バグの重大度に基づいて修正をリリースするかどうかを決定します。

エラーは重大度によって異なります。 したがって、S4 または S3 エラーは、ピクセルやアイコンの位置ずれなど、スタイルに関するものになる可能性があります。 これも同様に重要ですが、ワークフローには大きな影響はありません。つまり、このような S3 または S4 エラーに対する修正が作成される可能性は低い、と Marin 氏は説明します。

ただし、脆弱性 S1 または S2 は、ユーザーが最新バージョンに更新する必要がないこと、またはユーザーのワークフローに影響を与える重大なバグがあることを意味します。 それらがトラッカーに含まれている場合、多くのユーザーがそれらに遭遇しているため、リリース マネージャーはすぐに修正の準備を開始します。

脆弱性 S1 または S2 に対するパッチの準備が完了すると、リリース マネージャーはパッチのリリースを開始します。

たとえば、GitLab 12.10.1 パッチは、いくつかの障害となる問題が特定され、開発者がそれらの原因となっていた根本的な問題を修正した後に作成されました。 リリース マネージャーは、割り当てられた重大度レベルの正確性を評価し、確認後、修正をリリースするプロセスが開始されました。修正は、ブロック問題が発見されてから XNUMX 時間以内に準備が整いました。

大量の S4、S3、および S2 が蓄積されると、リリース マネージャーはコンテキストを調べて修正をリリースする緊急性を判断し、それらが一定数に達すると、すべて結合してリリースされます。 リリース後の修正やセキュリティ更新はブログ投稿にまとめられています。

リリースマネージャーがパッチを作成する方法

GitLab CI と ChatOps などのその他の機能を使用してパッチを生成します。 リリース マネージャーは、内部チャネルで ChatOps チームをアクティブにすることで修正のリリースをトリガーします。 #releases スラックで。

/chatops run release prepare 12.10.1

ChatOps は Slack 内で動作してさまざまなイベントをトリガーし、GitLab によって処理および実行されます。 たとえば、配信チームは、パッチをリリースするためにさまざまなことを自動化するために ChatOps を設定しました。

リリース マネージャーが Slack で ChatOps チームを開始すると、残りの作業は CICD を使用して GitLab で自動的に行われます。 リリース マネージャーがプロセスの主要なステップのいくつかをアクティブ化するため、リリース プロセス中に Slack の ChatOps と GitLab の間で双方向の通信が行われます。

以下のビデオは、GitLab 用のパッチを準備する技術的なプロセスを示しています。

gitlab.com での自動デプロイの仕組み

gitlab.com の更新に使用されるプロセスとツールは、パッチの作成に使用されるものと似ています。 リリース マネージャーの観点から見ると、gitlab.com の更新に必要な手動作業は少なくなります。

ChatOps を使用してデプロイメントを実行する代わりに、CI 機能を使用します。 スケジュールされたパイプラインこれを使用すると、リリース マネージャーは、必要な時間に特定のアクションが実行されるようにスケジュールを設定できます。 手動プロセスの代わりに、XNUMX 時間に XNUMX 回定期的に実行されるパイプラインがあり、GitLab プロジェクトに加えられた新しい変更をダウンロードし、パッケージ化してデプロイメントのスケジュールを設定し、テスト、QA、その他の必要な手順を自動的に実行します。

「そのため、gitlab.com を導入する前に、さまざまな環境で多くのデプロイメントを実行しています。それらの環境が良好な状態になり、テストで良好な結果が得られた後、リリース マネージャーが gitlab.com のデプロイメント アクションを開始します」と Marin 氏は言います。

gitlab.com の更新をサポートする CICD テクノロジーは、リリース マネージャーが gitlab.com への実稼働環境のデプロイメントを手動で開始する必要があるところまでプロセス全体を自動化します。

Marin は、以下のビデオで gitlab.com の更新プロセスについて詳しく説明しています。

配達チームは他に何をしますか?

gitlab.com の更新プロセスと社内での顧客へのパッチのリリースの主な違いは、後者のプロセスではより多くの時間と、リリース マネージャーによる手作業がより多く必要になることです。

「報告された問題やツールの問題、また XNUMX つのパッチをリリースするときに考慮する必要がある微妙なニュアンスが多数あるため、インストール済みのお客様へのパッチのリリースが遅れることがあります」と Marin 氏は言います。

デリバリー チームの短期的な目標の 3 つは、リリース マネージャーの手動作業の量を減らしてリリースを迅速化することです。 チームはリリース プロセスの簡素化、合理化、自動化に取り組んでおり、これにより重大度の低い問題 (S4 および SXNUMX、 約。 翻訳者）。 速度に重点を置くことが重要なパフォーマンス指標です。MTTP (マージ リクエストを受信して​​から結果を gitlab.com にデプロイするまでの時間) を現在の 50 時間から 8 時間に短縮する必要があります。

配信チームは、gitlab.com を Kubernetes ベースのインフラストラクチャに移行することにも取り組んでいます。

編集者注記: Kubernetes テクノロジーについてすでに聞いたことがある (そして知っていると私は疑いません) が、まだ実際に触ったことがない場合は、オンライン集中コースに参加することをお勧めします。 Kubernetes ベース、28月30日からXNUMX日まで開催されます。 Kubernetes メガ、14月16日からXNUMX日まで開催されます。 これにより、自信を持ってテクノロジーを操作して操作できるようになります。

これら XNUMX つのアプローチは、同じ目標、つまり gitlab.com とその施設のクライアントの両方に更新を迅速に配信することを追求するアプローチです。

何かアイデアやアドバイスはありますか?

誰でも GitLab に貢献することができます。また、読者からのフィードバックも歓迎します。 当社の配達チームに関するアイデアがございましたら、お気軽にお問い合わせください リクエストを作成する マークされた team: Delivery.

出所： habr.com