クラウドネイティブのヒント: CLI ツールを自動的に公開するにはどうすればよいでしょうか?

クラウドネイティブ時代において、CLI ツールは開発者の日常業務に欠かせないものとなっています。ただし、開発された CLI ツールを誰でも使用できるように共有する場合、手動リリースのみに頼っていると、特にマルチアーキテクチャおよびマルチプラットフォームの互換性を扱う場合には、非効率的であるだけでなく、エラーが発生しやすくなります。

では、CLI ツールのリリースを自動化するにはどうすればよいでしょうか?この論文は、この問題を調査し、一連の実用的な解決策を提案することを目的としています。

以下の共有では、主に Golang を例として使用します。ここで説明する自動ビルドとリリースの原則は普遍的であり、すべてのプログラミング言語に適用されることに注意することが重要です。したがって、ツールの作成にどの言語を使用するかに関係なく、これらのプラクティスは重要な参考価値を持ちます。

ビルドスクリプトの作成

自動ビルドの世界では、安定していてクロスプラットフォーム互換性のあるビルドスクリプトを作成することが重要です。 Golang は強力なクロスプラットフォームビルド機能を提供しており、 go build コマンドはこの目標を達成するための中核となります。例えば：

 CGO_ENABLED=0 GOOS=darwin GOARCH=amd64 go build -o fooctl-darwin-amd64 -v

このコマンド例は、プラットフォームおよびアーキテクチャ固有のバイナリを生成する際の Golang の柔軟性を強調しています。ビルドスクリプトでは、マルチプラットフォームのビルド要件をサポートするために、この柔軟性をさらに拡張する必要があります。

パラメータ化とデフォルト値の設定:

OUTPUT_DIR および BINARY_NAME 設定により、ユーザーは出力ディレクトリとバイナリファイル名をカスタマイズでき、スクリプトの汎用性が向上します。

BUILDPATH 変数はビルドパスを指定するために使用されます。これはスクリプトを実行するために必要なパラメータであり、ビルドプロセスの安定性を保証します。

クロスプラットフォームおよびアーキテクチャのサポート:

BUILD_GOOS および BUILD_GOARCH 変数を設定することにより、スクリプトはさまざまなオペレーティングシステムおよびアーキテクチャの構築要件を柔軟に処理できるようになり、適用性が向上します。
これらの変数のデフォルト値は go env を通じて取得されますが、パラメータによって上書きすることもできるため、柔軟性が向上します。

動的出力パス:

OUT 変数は、リリースバージョン (IS_RELEASE) かどうかに基づいて、出力ファイル名とパスを動的に調整します。この設計により、スクリプトはさまざまな使用シナリオ (開発テストや正式リリースなど) に応じて、さまざまな形式でファイル名を出力できるようになります。

特別な状況の取り扱い:

Windows の実行可能ファイルには通常この拡張子が必要であるため、Windows プラットフォーム (.exe 拡張子) に対する特別な処理が必要です。

gobuild.sh スクリプト

次の gobuild.sh スクリプトは上記の原則を実装し、クロスプラットフォームビルドの複雑さを単純なコマンドライン操作に変換します。

 OUTPUT_DIR=${4:-"bin"} BINARY_NAME=$(basename ${1}) BUILDPATH=./${1:?"path to build"} BUILD_GOOS=${GOOS:-$(go env GOOS)} BUILD_GOARCH=${GOARCH:-$(go env GOARCH)} GOBINARY=${GOBINARY:-go} LDFLAGS=$(version::ldflags) if [ $# -ge 2 ] && [ -n $2 ]; then BUILD_GOOS=$2 fi if [ $# -ge 3 ] && [ -n $3 ]; then BUILD_GOARCH=$3 fi OUT=${OUTPUT_DIR}/${1:?"output path"} if [ "${IS_RELEASE:-0}" == "1" ]; then OUT="${OUTPUT_DIR}/${BINARY_NAME}-${BUILD_GOOS}-${BUILD_GOARCH}" if [ "${BUILD_GOOS}" == "windows" ]; then OUT="${OUTPUT_DIR}/${BINARY_NAME}-${BUILD_GOOS}-${BUILD_GOARCH}.exe" fi fi CGO_ENABLED=0 GOOS=${BUILD_GOOS} GOARCH=${BUILD_GOARCH}${GOBINARY} build \ -ldflags="${LDFLAGS}" \ -o "${OUT}" \ "${BUILDPATH}"

このスクリプトは、マルチプラットフォームおよびマルチアーキテクチャのニーズに適応するだけでなく、さまざまなビルドシナリオに適応するのに十分な柔軟性と構成可能性も提供します。

Makefileと連携して完全自動構築を実現

さらに、Makefile を組み合わせることでビルドプロセスを自動化し、効率を向上させることができます。

 .PHONY: build-binaries BUILD_SCRIPT_PATH := ./hack/gobuild/gobuild.sh # 列出了需要构建的所有二进制文件，可管理多个项目的构建过程BINARIES := cmd/fooctl cmd/barctl # 通过ALLPLATFORMS 变量，我们定义了一系列目标平台和架构组合ALLPLATFORMS := linux/amd64 linux/arm64 darwin/amd64 darwin/arm64 windows/amd64 windows/arm64 # 构建所有组合build-binaries: $(foreach bin,$(BINARIES),$(foreach plat,$(ALLPLATFORMS),build-$(bin)-$(plat))) # 构建规则模板# 这个模板可以生成特定于每个二进制文件和平台组合的构建规则。 define BUILD_template build-$(1)-$(2): IS_RELEASE=1 $$(BUILD_SCRIPT_PATH) $(1) $$(subst /, ,$$(word 1,$$(subst -, ,$(2)))) $$(subst /, ,$$(word 2,$$(subst -, ,$(2)))) endef # 生成构建规则# 我们自动为每个二进制文件和平台组合生成了具体的构建规则。 $(foreach bin,$(BINARIES),$(foreach plat,$(ALLPLATFORMS),$(eval $(call BUILD_template,$(bin),$(plat)))))

この Makefile を使用すると、fooctl と barctl CLI ツールの両方を同時にビルドすることが非常に簡単になります。単純なコマンド「 make build-binaries 」でビルドプロセス全体をトリガーできるため、手動による介入が大幅に削減され、ビルドプロセスの一貫性と信頼性が確保されます。

まとめ

上記の詳細なビルドスクリプトと Makefile 構成を通じて、現代のソフトウェア開発における自動ビルドの威力と必要性がわかります。このアプローチはビルド効率を向上させるだけでなく、ソフトウェアの品質と安定性も向上させます。クラウドネイティブ時代において、自動ビルドは開発チームの効率性と製品の信頼性を向上させるための重要な戦略となっています。

GitLab CI/CD の CLI ツールをリリース

ビルドスクリプトが準備できたら、それを CI システムに統合できます。以下では、GitLab CI/CD を例に説明します。

GitLab CI/CD の中核となるのは、コードがコミットされたときに自動的に実行される、明確に定義された一連のジョブです。完全な継続的インテグレーションの場合、これらのジョブには通常、ビルド、テスト、コードレビュー (lint) などのステップが含まれます。しかし、この記事では、自動公開プロセスに焦点を当てます。

自動公開をトリガーする条件

自動リリースプロセスは Git タグに基づいて作成されます。開発者がリポジトリに新しいタグをプッシュすると、GitLab CI/CD はこのイベントをキャプチャし、事前定義されたリリースプロセスを開始します。

 rules: - if: $CI_COMMIT_TAG

この条件により、後続のビルド、アップロード、リリースジョブは新しいタグが作成された場合にのみ開始されます。

リリースジョブ

ステップ 1: バイナリをビルドします。ビルドバイナリフェーズでは、CI はさまざまなプラットフォームとアーキテクチャ用の CLI ツールバイナリをビルドして、ビルドプロセスの一貫性と再現性を確保します。

ステップ 2: ビルド製品をアップロードします。ビルドが完了したら、アップロードステージでバイナリファイルを GitLab のパッケージマネージャーまたはその他のストレージの場所にアップロードします。これにより、後続のリリースに必要なリソースが提供されます。

ステップ 3: GitLab に公開します。最後に、リリースステージでは、CI は release-cli ツールを使用してリリースを自動的に作成し、ビルドされたバイナリをリリースされたアセットとして使用します。

.gitlab-ci.yml からリリースを作成する

次の .gitlab-ci.yml スクリプトは、上記のリリースプロセスを実装します。

 stages: ... - build-binaries - upload - release build-binaries: stage: build-binaries image: golang:1.21.1 rules: - if: $CI_COMMIT_TAG script: - echo "Building binaries for all platforms and architectures..." - make build-binaries artifacts: paths: - bin upload: stage: upload image: curlimages/curl:latest rules: - if: $CI_COMMIT_TAG script: - echo "Uploading binaries..." - > for binary in ./bin/*; do curl --header "JOB-TOKEN: $CI_JOB_TOKEN" \ --upload-file $binary \ "${PACKAGE_REGISTRY_URL}/$(basename $binary)"; done release: stage: release image: registry.gitlab.com/gitlab-org/release-cli:latest rules: - if: $CI_COMMIT_TAG script: - echo "Creating a release for $CI_COMMIT_TAG" - | ASSET_LINKS="" for binary in ./bin/*; do LINK="{\"name\":\"$(basename $binary)\", \"url\":\"${PACKAGE_REGISTRY_URL}/$(basename $binary)\"}" ASSET_LINKS="${ASSET_LINKS},${LINK}" done ASSET_LINKS="[${ASSET_LINKS:1}]" - > release-cli create \ --name "Release $CI_COMMIT_TAG" \ --tag-name $CI_COMMIT_TAG \ --description "Created using the release-cli: $CI_COMMIT_REF_NAME-$CI_JOB_ID" \ --ref $CI_COMMIT_SHA \ --assets-link "$ASSET_LINKS"

上記の例では、CLI ツールのバイナリをビルドし、Gitlab リリースページにアップロードします。ユーザーは、Gitlab リリースページから、自分のプラットフォームに適したバイナリパッケージを見つけてダウンロードできます。

写真

GitLab CI プロセスの詳細については、プロジェクトを参照してください: https://gitlab.com/lqshow/clireleaseautomator

まとめ

このプロセスにより、CLI ツールのリリースプロセスが大幅に簡素化され、開発者は後続のビルドおよびリリース手順ではなくコード開発に集中できるようになります。これらの手順を自動化すると、すべてのリリースが高速で、一貫性があり、エラーがなくなり、ソフトウェアの全体的な品質と信頼性が向上します。

リリースCLIツールはGoReleaserを使用する

上記のプロセスが比較的面倒であり、スクリプトの準備プロセスも複雑であることに気付くのは難しくありません。ここで、このプロセスを楽にするツール、GoReleaser[1]を紹介します。

これは、特に Golang で書かれたプロジェクトにとって変革的なツールです。従来の手動構成やスクリプト作成と比較して、GoReleaser はより効率的で簡潔な自動リリース方法を提供します。

GoReleaserの利点

GoReleaser の設計哲学は、「一度設定すればどこでも実行できる」というものです。単一の構成ファイルを通じてリリースプロセス全体を制御します。この構成ファイルは、バイナリの構築方法、パッケージ化方法、バージョン情報の処理方法、さまざまなプラットフォームへの公開方法を定義します。具体的には、GoReleaser の利点は次のとおりです。

簡素化されたビルドプロセス: 事前定義されたテンプレートを使用すると、GoReleaser は複雑なスクリプトを記述することなく、さまざまなプラットフォームやアーキテクチャ用のバイナリを自動的にビルドできます。
柔軟なパッケージングと公開: 複数の形式でのパッケージングオプションと、主要なコードホスティングプラットフォームとのシームレスな統合をサポートします。
高度な設定が可能: ビルドオプションからリリース設定まで、GoReleaser ではさまざまなプロジェクトのニーズに合わせて高度なカスタマイズが可能です。

GoReleaserの設定と使用

GoReleaser を使用するための最初のステップは、プロジェクトのルートディレクトリに .goreleaser.yml 構成ファイルを作成することです。 goreleaser init コマンドを使用すると、初期構成をすばやく生成できます。このファイルには、構築、パッケージ化、公開のプロセス全体が網羅されています。

.goreleaser.yml を設定した後、 goreleaser はデフォルトでコンパイルされたファイルを dist ディレクトリに出力するので、 .gitignore を調整して dist を追加する必要があります。

例を見てみましょう:

 # .goreleaser.yml 示例builds: - id: fooctl binary: fooctl main: ./cmd/fooctl ldflags: - -s -w - -X gitlab.com/lqshow/clireleaseautomator-with-goreleaser/version.gitVersinotallow={{.Version}} - -X gitlab.com/lqshow/clireleaseautomator-with-goreleaser/version.gitCommit={{.ShortCommit}} goos: - linux - darwin - windows goarch: - amd64 - arm64 - id: barctl binary: barctl main: ./cmd/barctl ldflags: - -s -w - -X gitlab.com/lqshow/clireleaseautomator-with-goreleaser/version.gitVersinotallow={{.Version}} - -X gitlab.com/lqshow/clireleaseautomator-with-goreleaser/version.gitCommit={{.ShortCommit}} goos: - linux - darwin - windows goarch: - amd64 - arm64

このシンプルで明確な構成ファイルには、実際に先ほど紹介した 2 つのモジュールが含まれています。これにより、シェルスクリプトと Makefile ファイルを記述する必要がなくなり、プロセス全体がより柔軟かつ効率的になります。

GitLab CI での GoReleaser の統合

.gitlab-ci.yml ファイルでは、単純なリリースジョブを定義するだけで済みます。ちなみに、CI/CD で GTILAB_TOKEN 変数を設定することを忘れないでください。

 stages: - release release: stage: release image: name: goreleaser/goreleaser entrypoint: [''] only: - tags variables: GIT_DEPTH: 0 GITLAB_TOKEN: $GITLAB_TOKEN script: - goreleaserrelease--clean

実行ログを確認すると、GoReleaser が自動的に実行された後、ビルド、アップロード、公開のプロセス全体が含まれていることがわかります。