マージした結果に対するパイプライン
フィーチャーブランチ(ソースブランチ)で作業している場合、頻繁にリベースしないと、時間の経過とともにターゲットブランチから乖離してしまいます。 これにより、ソースブランチとターゲットブランチの両方のパイプラインが成功していて、マージコンフリクトは発生しない状態であっても、 ソースブランチをターゲットブランチにマージした結果のパイププラインが失敗する可能性があります。
マージした結果に対するパイプラインでは、ソースブランチとターゲットブランチのマージした新しい参照を自動的に生成し、 その参照に対してパイプラインを実行することで、マージした結果のパイプラインが成功することを確認します。
マージリクエストパイプラインを使用しており、バージョン 11.8 以前のプライベートな GitLab ランナーを使用している場合は、 gitlab-ee#11122 に書かれている問題が発生しないようにランナーをアップグレードする必要があります。 GitLab.com の共有ランナーを使用しているユーザには影響ありません。
複数行の変更を提案する
マージリクエストによる共同作業には、問題の発見や解決策の提案が含まれることがよくあります。GitLab 11.6 では、単一の行への 変更の提案 のサポートを導入しました。
11.10 では、マージリクエストの差分にコメントを残す場合に、複数行に対して変更を提案し、ソースブランチに対する書き込み権限があるすべてのユーザがシングルクリックでその変更を受け入れられるようになりました。 この新機能により、コピー/ペーストの古いワークフローを回避できます。
スコープ付きラベル
課題やマージリクエストやエピックにおいて、カスタムフィールドやカスタムワークフローのユースケースを解決するために、スコープ付きラベルを利用できます。 スコープ付きラベルは、ラベルのタイトルを2つのコロンで区切るだけで設定できます。
例えば、機能の対象となるプラットフォームのオペレーティングシステムを区別するために、課題の中にカスタムフィールドが必要だとします。 そして、それぞれの課題には1つのプラットフォームだけを設定したいとします。 その場合は、必要に応じて platform::iOS, platform::Android, platform::Linux のようなラベルを作成します。 これらのラベルのいずれかを特定の課題に適用すると、必要に応じて platform:: で始まる他の既存のラベルが自動的に削除されます。
また、特定のチームのワークフローの状態を表す workflow::development, workflow::review および workflow::deployed というラベルがあるとします。 開発者が workflow::development ラベルがすでに適用された課題を workflow::review に進めたい場合には、単純にその workflow::review ラベルを適用します。 すると、workflow::development ラベルは自動的に削除されます。 この動作は、チームのワークフローを表す課題ボードで、課題を workflow::development から workflow::review に移動する動作と同じです。 しかし、スコープ付きラベルを使用すると、課題ボードで作業していないチームメンバーであっても、ワークフローの状態を一貫して変更することができます。
コンテナレジストリの徹底的なクリーンアップ
CI パイプラインでの一般的なコンテナレジストリの使い方だと、通常は同じタグに対して多くの修正を繰り返しプッシュすることになります。 デフォルトの動作では Docker Distribution の実装方法により、システム内のすべてのリビジョンが保持されます。 そのため、このような使用パターンではストレージ容量が大量に消費されてしまいます。 これらの繰り返された修正をクリーンアップする簡単な方法として、管理者は registry-garbage-collect コマンドで -m パラメータを使うことにより、貴重なストレージ容量を解放することができます。
CI ランナーの実行時間を分単位で追加購入
GitLab.com の有料プラン (Gold, Silver, Bronze) のユーザは、CI ランナーの実行時間を分単位で追加で購入できるようになりました。 以前は、プランに含まれている実行時間に制限されていました。 この改善により、実行時間がオーバーしそうな時は追加の実行時間を購入することで、パイプラインの停止によるサービス中断を防止できます。
現在の価格は 8 ドル / 1,000 分で、追加購入の上限はありません。 毎月の割り当て分が消費された後に追加分が使われ、毎月末に追加分が残っていると翌月に繰り越しされます。 将来のリリース では、これを無料プランにも拡張することを目指しています。
構成可能な Auto DevOps
チームは Auto DevOps を使うことにより、ほとんど、もしくは全く労力をかけずに最新の DevOps プラクティスを採用できます。 GitLab 11.10 からは Auto DevOps の各ジョブは 独立したテンプレート として利用できるようになりました。 ユーザは GitLab CI の includes 機能 により、 独自のカスタム gitlab-ci.yml を使い続けながら Auto DevOps の特定の段階のみを含めることができます。 これにより、チームはアップストリームで行われた更新を利用しながら、必要なジョブだけを含めることができます。
GitLab.com での SCIM を利用した グループメンバーの自動的な管理
GitLab.com では、今まではグループメンバーシップの管理を手動で行わなければいけませんでした。 しかし、SAML SSO が使えるようになり、SCIM でグループメンバーシップを管理できるようになりました。 これにより、GitLab.com でユーザを作成、削除、および更新できます。
この機能は、集中型 ID プロバイダを使用して多数のユーザを管理する企業にとって特に便利です。 Azure Active Directory のようなプロバイダーを唯一の正しい情報源として使うことができます - この場合、ユーザが手動ではなく、ID プロバイダに基づいて自動的にプロビジョニングされたり、もしくはプロビジョニングが解除されることを気にしてください。
SAML プロバイダを用いた GitLab.com へのサインイン
グループ用の SAML ベースの SSO では、ユーザが GitLab のユーザ資格情報と ID プロバイダーの両方を使用してサインインする必要がありました。 現在は SSO を使用して、ユーザは設定されたグループにリンクされている GitLab ユーザに直ちにサインインできるようになります。
これにより、二段階認証する必要がないので、GitLab.com で SAML SSO を使用する企業にとってより便利になります。
