HabréでのGitLab CIウィーク！ 2015年には、GitLabに組み込まれた継続的インテグレーションシステムについて既に書きました。 GitLabは、UNIX方式の理想を裏切って、1つのアプリケーションに統合しすぎる機能が多すぎると非難されることがよくあります。 しかし、これらの機能を使用するのはどれほど便利なことでしょう！ 私たちの公開から1年半が経ち、彼らは「環境」を作成し、「製品にロール」ボタンを作成する機能を追加し、他の多くの改良を加えました。 カットの下で、得られた経験、小規模なチームが自動的に収集し、テレフォニー用のVoximplantスクリプトだけでなく、他のプロジェクト（サイトおよびサービス）を販売/ステージに配置する方法について説明します。
ブランチまたは環境？
自動アセンブリを実行してプロジェクトをレイアウトすると、入力時に質問が表示されます。どのレイアウトをどこでレイアウトするかを決定する方法は？ いくつかのアプローチがあります。 そして前回の記事で最も簡単なものについて説明しました。CIシステムはブランチに応じて収集およびアップロードします。 それを「マスター」（または「マスター安定版」がある場合は「開発」）に配置し、アセンブリをステージング用にレイアウトします。 「prod」（または「master stable」がある場合は「master」）のMerjim、およびアセンブリはprodに配置されます。 このアプローチには長所と短所があります。 個人的には、このアプローチでは、ブランチの2つの目的はあまり好きではありません。多くのマイクロサービスでは、1つの「マスター」で十分であり、「prod」は「put on prod」ボタンになります。 さらに、ブランチテストは興味深い話になります。
GitLabの作成者がバージョン8.9で提案した2番目のオプションは、「アセンブルの方法と配置場所」の個別の抽象化です。 抽象化は「環境」と呼ばれ、GitLabユーザーインターフェイスのボタンをクリックするだけでアセンブリを展開できます。 次のようになります。継続的インテグレーションYAML構成ファイルで、環境に任意の名前を設定し、アセンブリとレイアウトのコードを記述します。
抽象化は、GitLabインターフェースに「ここにロール」ボタンを追加するだけです。 ボタンを押すことにより、ステージングおよび製品で自動的に展開することは非常に便利です。 ボタンを押すことにより、「マスター」からのステージングに自動的にロールアウトすることができます（マニュアルが存在せず、マスターのみが指定されている場合）。
コピーペーストと戦う
Continuous IntegrationスクリプトはYAMLで記述されています。 これは、いくつかのボーナスがあるPython型のJSONです。 最近のバージョンでサポートが登場したこれらのボーナスの1つにアンカーがあります。構成の一部に識別子を付け、別の場所で再利用します。 これにより、一般化されたビルドおよびロールスクリプトを記述し、それを異なる環境に「コピー」して、環境変数のみを変更できます。 たとえば、Voximplant NDFLka.ruプラットフォームでは、複雑なビジネスロジックに従って着信コールを自動的に配信するサービスが作成されました。 このようなサービスでは、異なる電話番号で開発および製品アプリケーションを作成できます（開発者は、Gotem Cityで電話番号を使用でき、月額1セントの費用がかかります）。その後、自動的に開発者をロールアウトし、責任者が手動で製品を作成します。テスト結果によると：
Dockerを使用してビルドする
最新のすべてのCIと同様に、GitLabは、コンピューター上で「ランナー」を実行するように要求し、「スクリプト」で記述したスクリプトはこのマシンで実行されます。 多くの異なるプロジェクトがある場合、それらのアセンブリと展開のために、ツールチェーンの異なる、しばしば互換性のないバージョンが必要になる場合があります。 GitLabは、この問題に対するソリューションを提供し、Dockerとシームレスに統合します。 「image」フィールドに目的のコンテナのイメージを設定するだけで十分です。GitLabは指定されたコンテナで「script」コマンドを実行します。 さらに、さまざまなアセンブリ手順に対して、さまざまなコンテナを使用して、それらの間にアセンブリの結果を「アーティファクト」として渡すことができます。 実際には、プロジェクトをビルドするための独自のDockerコンテナを作成し、プロジェクト自体と同じGitリポジトリに保持し、git urlで指定すると便利です。
期待すること
Gitlabは非常に高速に開発されています。 過去数か月にわたって、リアルタイムCIマッピング、kubernetesでの自動展開の最初のテスト実装、およびその他の多くの小さな改善を受け取りました。 巨大な収穫機は常に良いとは限りません。 しかし、GitLabの場合、彼らが製品の開発を続ければ、ソース管理とタスク管理システムとシームレスに統合する最高のCIソリューションを手に入れることができると信じています。 あなたの意見は？