CIの使用を開始する方法に関するGitLabブログの記事の翻訳を公開しています。 Gitlabの投稿の他の翻訳は、 Softmartのブログで見つけることができます 。
継続的インテグレーション（CI）の概念とその目的について何も知らないことを少し想像してみてください。 または、あなたはすべてを忘れました。 いずれにせよ、基本から始めましょう。
コードベース全体が2つのテキストファイルで構成されるプロジェクトに取り組んでいると想像してください。 さらに、これらのファイルを連結する場合、結果が常に「Hello world」というフレーズになることが非常に重要です。 この条件が満たされない場合、チーム全体が月給を失います。 はい、すべてがとても深刻です。
ある責任ある開発者が、各コードを顧客に送信する前に実行する必要がある小さなスクリプトを作成しました。 スクリプトは重要です：
cat file1.txt file2.txt | grep -q "Hello world"
問題は、チームに10人の開発者がいますが、ヒューマンファクターがまだキャンセルされていないことです。
1週間前、1人の新参者がコードを送信する前にスクリプトを実行するのを忘れていたため、3人の顧客が壊れたアセンブリを受け取りました。 将来的にはこれを避けたいので、あなたはこの問題に終止符を打つことにします。 幸いなことに、あなたのコードはすでにGitLab上にあり、 組み込みCIシステムを覚えています 。 さらに、カンファレンスでは、CIがテストに使用されると聞きました...
CIで最初のテストを実行します
ドキュメントの検索と読み取りに数分費やした後、必要なことは.gitlab-ci.yml
2行のコードを追加するだけであることが.gitlab-ci.yml
。
test: script: cat file1.txt file2.txt | grep -q 'Hello world'
追加、コミット-そして歓声！ ビルド成功！
2番目のファイル「world」を「Africa」に変更し、何が起こるかを確認します。
ビルドは期待どおりに失敗しました。
それで、自動化されたテストができました。 GitLab CIは、新しいコードをリポジトリにプッシュするたびにテストスクリプトを実行します。
アセンブリ結果をロードする機能
次のビジネス要件は、顧客に送信する前にコードをアーカイブすることです。 なぜそれも自動化しないのですか？
実行する必要があるのは、CIの別のタスクを定義することだけです。 それを「パッケージ」と呼びます：
test: script: cat file1.txt file2.txt | grep -q 'Hello world' package: script: cat file1.txt file2.txt | gzip > package.gz
その結果、2番目のタブが表示されます。
ただし、新しいファイルはアセンブリアーティファクトであり、ダウンロードできるようにすることを明確にするのを忘れていました。 これは、 artifacts
セクションを追加することで簡単に修正できます。
test: script: cat file1.txt file2.txt | grep -q 'Hello world' package: script: cat file1.txt file2.txt | gzip > packaged.gz artifacts: paths: - packaged.gz
確認しています...すべてが整っています：
いいね！ ただし、1つの問題が残っていました。タスクは並行して実行されるため、テストが失敗した場合にアプリケーションをアーカイブする必要はありません。
一貫したタスク実行
「パッケージ」タスクは、テストが正常に合格した場合にのみ完了する必要があります。 ステージを導入して、タスクの順序を定義します。
stages: - test - package test: stage: test script: cat file1.txt file2.txt | grep -q 'Hello world' package: stage: package script: cat file1.txt file2.txt | gzip > packaged.gz artifacts: paths: - packaged.gz
動作するはずです。
また、コンパイル（この場合はファイル連結）に時間がかかることを忘れないでください。したがって、2回実行しないでください。 コンパイルのために別の段階を導入します：
stages: - compile - test - package compile: stage: compile script: cat file1.txt file2.txt > compiled.txt artifacts: paths: - compiled.txt test: stage: test script: cat compiled.txt | grep -q 'Hello world' package: stage: package script: cat compiled.txt | gzip > packaged.gz artifacts: paths: - packaged.gz
結果のアーティファクトを見てみましょう。
「コンパイル」ファイルのダウンロードは役に立たないので、一時的なアーティファクトの寿命を20分に制限します。
compile: stage: compile script: cat file1.txt file2.txt > compiled.txt artifacts: paths: - compiled.txt expire_in: 20 minutes
構成の最終的な機能は印象的です：
- アプリケーションのコンパイル、テスト、アーカイブの3つの連続した段階があります。
- コンパイルステージの結果は後続のステージに渡されます。つまり、アプリケーションは1回だけコンパイルされます（ワークフローが高速化されます）。
- アプリケーションのアーカイブバージョンは、将来使用するためにアセンブリアーティファクトに格納されます。
どのDockerイメージが最適ですか
進歩は明らかです。 しかし、私たちの努力にもかかわらず、アセンブリはまだ遅いです。 ログを見てください：
何、ごめん？ Ruby 2.1？
なぜここにRubyがあるのですか？ そして、そのGitLab.comはDockerイメージを使用してアセンブリを実行し、デフォルトではruby:2.1
イメージを使用します 。 もちろん、このイメージには必要のない多くのパッケージが含まれています。 Googleに支援を求めたところ、 alpine
画像があり、ほとんど裸のLinux画像であることがわかりました。
この画像を使用するには、 image: alpine
を.gitlab-ci.yml
ます。
これにより、アセンブリ時間はほぼ3分短縮されます。
一般的に、 非常に 多くの 異なる 画像が無料で利用できるため、スタック用に簡単に選択できます。 主なことは、追加機能を含まない画像の方が適していることを覚えておくことです。このアプローチでは、ダウンロード時間が最小限に抑えられます。
複雑なシナリオで作業する
ここで、アプリケーションを.gz
アーカイブではなく.iso
イメージとして配信することを希望する新しい顧客がいることを想像してください。 ビルドプロセス全体がCIを介して実装されるため、必要なことは別のタスクを追加することだけです。 ISOイメージは、 mkisofsコマンドを使用して作成されます。 その結果、構成ファイルは次のようになります。
image: alpine stages: - compile - test - package # ... "compile" "test" pack-gz: stage: package script: cat compiled.txt | gzip > packaged.gz artifacts: paths: - packaged.gz pack-iso: stage: package script: - mkisofs -o ./packaged.iso ./compiled.txt artifacts: paths: - packaged.iso
タスク名は同じである必要はないことに注意してください。 さらに、この場合、1段階でのタスクの並列実行は不可能です。 したがって、同じタスク名とステージ名を偶然として扱います。
一方、アセンブリは失敗しました：
問題は、 mkisofs
コマンドがalpine
イメージの一部ではないため、個別にインストールする必要があることです。
追加ソフトウェアのインストール
Alpine Linux Webサイトでは、 mkisofs
はxorriso
およびcdrkit
パッケージの一部であるとxorriso
cdrkit
ます。 パッケージをインストールするには、次のコマンドを実行する必要があります。
echo "ipv6" >> /etc/modules # apk update # apk add xorriso #
これらはすべて有効なCIコマンドでもあります。 script
セクションのコマンドの完全なリストは次のようになりscript
。
script: - echo "ipv6" >> /etc/modules - apk update - apk add xorriso - mkisofs -o ./packaged.iso ./compiled.txt
一方、 script
セクションの前、つまりbefore_script
セクションでパッケージをインストールするコマンドを実行する方が意味的にはより正確です。 このセクションを構成ファイルの上位レベルに配置すると、すべてのタスクの前にコマンドが実行されます。 ただし、この場合、特定のタスクの前にbefore_script
を実行するだけで十分です。
.gitlab-ci.yml
最終バージョン：
image: alpine stages: - compile - test - package compile: stage: compile script: cat file1.txt file2.txt > compiled.txt artifacts: paths: - compiled.txt expire_in: 20 minutes test: stage: test script: cat compiled.txt | grep -q 'Hello world' pack-gz: stage: package script: cat compiled.txt | gzip > packaged.gz artifacts: paths: - packaged.gz pack-iso: stage: package before_script: - echo "ipv6" >> /etc/modules - apk update - apk add xorriso script: - mkisofs -o ./packaged.iso ./compiled.txt artifacts: paths: - packaged.iso
しかし、コンベアを作成しました！ 3つの連続したステージがあり、 package
ステージのpack-gz
およびpack-iso
タスクが並行して実行されます。
まとめると
この記事ではGitLab CIのすべての機能をカバーしているわけではありませんが、ここではこれについて詳しく見ていきましょう。 この短編をお楽しみください。 ここに示されている例は、意図的に些細なものです。これは、なじみのない技術に気を取られることなく、CI操作の原理を明確に示すために行われました。 学んだことをまとめましょう。
- 特定の作業をGitLab CIに転送するには、1つ以上のタスクを
.gitlab-ci.yml
で定義する必要があります。 - タスクには名前を割り当てる必要があります。後で混乱しないように、意味のある名前にすることをお勧めします。
- 各タスクには、 キーワードで定義されたGitLab CIのルールと指示のセットが含まれています。
- タスクは順番に、並行して実行できます。または、パイプラインを作成して独自の実行順序を設定できます。
- タスク間でファイルを転送し、インターフェースを介して後続のダウンロード用にビルドアーティファクトとして保存することができます。
この記事の最後のセクションでは、この例で使用される用語とキーワードのより形式化されたリスト、およびGitLab CI機能の詳細な説明へのリンクを提供します。
キーワードの説明とドキュメントリンク
| キーワード/用語 | 説明 |
|---|---|
| .gitlab-ci.yml | すべてのプロジェクトアセンブリ定義を含む構成ファイル |
| 台本 | 実行可能なシェルスクリプトを定義します |
| before_script | すべてのタスクの前に実行するコマンドを定義します |
| 画像 | 使用するDockerイメージを定義します。 |
| 舞台 | パイプラインのステージを定義します（デフォルトでtest
） |
| アーティファクト | ビルドアーティファクトのリストを定義します |
| アーティファクト：expire_in | 一定時間後にロードされたアーティファクトを削除するために使用されます。 |
| パイプライン | コンベア-段階的に実行されるアセンブリのセット |
GitLab CIを使用する他の例にも注意してください。