機能ブランチのワークフローの作成

この記事ではへの紹介 Github アクションCI ワークフローを設定する方法を紹介します (継続的インテグレーション) と呼ばれることが多い 「機能ブランチ」。

エニックス社内で使用するために最近フォークした具体的なプロジェクトでそれを説明します。 プロジェクト自体がこの記事の主な主題ではない場合でも、OS のシステム拡張イメージを生成できることを指摘しておくとよいでしょう。 台車。

なぜフィーチャーブランチワークフローなのか?

このプロジェクトには何人かの同僚が協力しているため、次のことを可能にするためには CI ワークフローの統合が不可欠です。 同時に開発に参加する など 変更を効果的にテストする コードベースや他の貢献者の作業に影響を与えることなく。

すべての開発者は次の能力を備えている必要があります。 アーティファクトを作成する (この使用例では、これはシステム拡張イメージです) 個別にテストする する前に マージリクエスト 最後の。 これらのアーティファクトは、パブリック リリース (誰でも利用可能) またはプライベート (開発段階中) の形式で公開されます。

それは私たちにとって不可欠です:

• D’すべての人がアクセスできる公開リリースの作成を避ける 開発段階のユーザー。
• D’リリース作成プロセスを自動化する 当社が以前に確立した基準に従って。

これらの前提条件に基づいて、 ワークフローでこれらのステップを想像することができます :

• プロジェクトソースの回復。
• 私たちのアーティファクトの作成;
• 非公開となるリリースの作成 (=ドラフトリリース) または開発者のニーズに応じてパブリック。

ワークフローを視覚的に表すと次のようになります。

Github アクションを使用する理由

Github エコシステムの中心となるのは、 Github アクション、 そして 自動化ツール 以下のために作られました 開発者のワークフローを改善および合理化する。

技術的な観点から見ると、このツールにはいくつかの点が際立っています。 ただし、私のリストは網羅的ではないため、ツールの完全な分析ではないことに注意してください… 🙂

利点

• ワークフローの可視性 : Github Actions を使用すると、ワークフローがユーザー インターフェイスにネイティブに統合されます。 これにより、履歴を保持しながら実行を明確に可視化できます。
• Github マーケットプレイス ：これは Github Actions の大きな強みの 1 つであり、開発者はさまざまな機能にアクセスできます。行動 事前構築済み。
• Githubとの統合 ： システム行動 Github のコード リポジトリとネイティブに統合されているため、このタイプの開発環境での自動化のセットアップが簡単になります。
• シンプルな構成 : ワークフロー管理は YAML 設定ファイルを介して簡単に実行できます。

短所

• 一般公開 : 特に公開リリース中のエラーは、一般に公開されます。 これには、ワークフローをトリガーする前に、より一層の努力と慎重な検証が必要です。
• のパフォーマンス ランナー : 執行者 (名前付き) ですが、 ランナー Github の用語で) はかなりの使用期間を提供しますが、特にコンパイルなどの集中的なタスクを実行する場合には、能力が不十分であるとみなされることがあります。 これにより、実行時間が長くなる場合があります。
• ワークフローの検証が存在しない : ワークフローの分析やデバッグに役立つネイティブ ツールがないのは残念です。
• 複雑な使用例 : 複数のコード リポジトリ間の依存関係など、特定の構成はセットアップが複雑になる場合があります。

私たちの場合、コードは統合がネイティブである Github リポジトリでホストされているため、Github Action の使用は簡単です。 ただし、実装することは可能です。 他の CI/CD ソリューションを使用した同様の機能ブランチ ワークフロー、特に Gitlab CI と Tekton が気に入っています。

Github Actions を使用したフィーチャー ブランチ ワークフローの実装

Github Actions の観点から言えば、 仕事 一連のステップを表します（または ステップ) 同じ上で実行されます ランナー （執行者）。

ワークフローのトリガー

私たちのワークフローは比較的単純なので、次のように書きます。 唯一 仕事 それをいくつかに切り分けます ステップ。 まず最初に宣言します。 ワークフローをトリガーする方法 :

name: Build and release Systemd sysext images
on:
  workflow_dispatch:

ここでのトリガー メソッドは非常に単純で、「Github Web インターフェイスを使用してワークフローを起動します」という内容で構成されています。 ただし、ニーズに応じて他のメソッドを使用することも完全に可能であることに注意してください。 プルリクエスト、コードを特定のブランチにプッシュするときなど。

ワークフローのレ・エテープ

ワークフローの最初のステップ (おそらく 99% の CI ワークフローで同じです) は、プロジェクト コードを取得することです。

    steps:
      # récupération des sources du projet
      - uses: actions/checkout@v3

次に、 ステップ の 建てる 取り組んでいるプロジェクトに大きく依存します。 場合によっては、コンテナー イメージの構築やバイナリのコンパイルが含まれる場合があります。 私たちの場合、それは約です シェルスクリプトを実行してアーティファクトを構築します。

これ ステップ ヴァ 一定数のファイルを生成する : システム拡張イメージと関連するチェックサム。 ワークフローの少し後のほうで必要になります。 関連する YAML は次のとおりです。

      - name: Build
        run: |
          set -euo pipefail

          images=(
              "teleport-9.3.26"
              "teleport-10.3.16"
              "teleport-11.3.22"
          )

          for image in ${images[@]}; do
              component="${image%-*}"
              version="${image#*-}"
              "./create_${component}_sysext.sh" "${version}" 
                "${component}"
              mv "${component}.raw" "${image}.raw"
          done

          sha256sum *.raw > SHA256SUMS          

の Github アクションのマーケットプレイス 本当に完全で見つけやすいです 行動 特定のニーズをカバーします。 評価システムも特に興味深いもので、確実に アクション 機能的。

私たちが望むように Github で公開リリースを作成する 私たちの結果を参考にして、 建てるを使用します。 アクション 人気のある ：https://github.com/softprops/action-gh-release。

正しく機能するには、これは アクション git タグを割り当てる必要があります。 したがって、ワークフローをブランチではなくタグ (ブランチの最後のコミットに相当します) で起動します。

これ ステップ これは、プライベートまたはパブリックの 2 種類のリリースに共通です。 したがって、私たちがどのような状況に置かれているのかを判断することが重要です。 これを行うには、git タグに従ってこの区別が行われます。

私たちの場合、簡単にするために、 以下の命名法 :

• デジタルタグは公開に対応します。
• 開発には英数字のタグが使用されます。

2つ追加しましょう ステップ 私たちのワークフローに: 1 つは タグを回復する、もう1つは リリースの種類を決定する。

      - name: Get git tag
        id: tag
        uses: devops-actions/[email protected]

      - name: (Pre)Release check
        run: |
          if [[ ${{ steps.tag.outputs.tag }} =~ ^[0-9]+$ ]]; then
             echo "TAG_TYPE=numeric" >> $GITHUB_ENV
          else
             echo "TAG_TYPE=alphanumeric" >> $GITHUB_ENV
          fi          

ここでは、次の手順で使用する環境変数を使用します。 ステップ 作成するリリースのタイプを決定します。

最後に、前のステップで生成されたアーティファクトを使用してリリースを作成できます。 建てる :

      - name: Release
        uses: softprops/action-gh-release@v1
        if: env.TAG_TYPE == 'numeric'
        with:
          files: |
            SHA256SUMS
            *.raw            
      - name: Draft Release
        uses: softprops/action-gh-release@v1
        if: env.TAG_TYPE == 'alphanumeric'
        with:
          draft: true
          files: |
            SHA256SUMS
            *.raw            

開発ブランチの場合は、一般に公開されていないプライベート リリースを作成することに注意してください。 これにより、アーティファクトを回復してテストできるようになります。

ステップの表示 Github アクション

以前、Github Actions の主要な資産であるワークフローの可視性について説明しました。 これは、ワークフローを構築するときに当てはまります。 仕事 相互依存だけでなく、 仕事 多くは ステップ (この記事で紹介されている機能ブランチのワークフローに関して):

Github Actions では、それぞれの詳細な表示も提供します。 ステップ 私たちのワークフローの 実行ログ。 これは、ブランチの構築結果をテストするのに最適です。

結論

この「フィーチャー ブランチ」ワークフローの作成を通じて、これを確認することができました。 Github Actions は、機能豊富で柔軟性が高く、比較的使いやすい CI/CD ソリューションです。

その資産の中には、マーケットプレイスには数多くのものが含まれています 行動 使用する準備ができて。 広く使用されているこのソリューションも 他の多くのツールと簡単に統合してワークフローを強化できる アプリケーションを運用環境に導入する前の統合とテスト。

開発者のニーズと好みに応じて、次のことができます。 完全な CI/CD チェーンを展開および管理する Github Actions ベースでも Gitlab CI ベースでも、エニックス インフラストラクチャ上で動作します。 サポートが必要な場合は、お気軽にお問い合わせください。 🙂

次の記事をお見逃しなく DevOps など クラウドネイティブ！ フォローする エニックス の上 ツイッター！