GitLab 9.1：サービスデスク、バーンダウンチャート、およびカナリア展開がリリースされました

GitLabは、アプリケーションライフサイクルのすべての段階で、さまざまな時間枠で建設的なフィードバックを提供するように設計されています。

GitLab 9.1はカナリアデプロイメントを導入しました 。 インフラストラクチャのごく一部に新しいコードを展開できます。 問題が見つかった場合は、ごく一部のユーザーにしか影響を与えないため、前のバージョンに簡単にロールバックできます。 これは戦闘環境からの素早いフィードバックです 。

新しいService Desk機能を使用すると、ユーザーはプロジェクトごとに質問を送信し、問題を特別なメールアドレスに報告できます。 ユーザーからの手紙により、Service Deskはプロジェクトの機密タスク（問題）を開始します。 誰かがタスクにコメントすると、ユーザーはこのコメントを返信メールで受け取ります。 これは、GitLabに直接組み込まれたユーザーフィードバックチャネルです。

GitLab 9.1はバーンダウンチャートも導入しました 。 彼らはチームの仕事についてフィードバックをします 。 特定のマイルストーンに関連するタスクで作業がどのように進行しているかを確認し、開発プロセスをタイムリーに調整できます。

最近の記事がHerokuのブログに投稿され 、GitLab CI継続的統合サーバー（GitLab自体に組み込まれている）がStack Overflowの問題でライバルのTravis CIをしのいでいます。 Googleトレンドでは、検索クエリの人気において同様の結果が示されています。 そして最後に、GitLabは世界中で、3つのケースのうち2つでgitを操作するためのセルフホストサービスとして使用されています。 ご支援ありがとうございました！

今月の（ MVP ）- マキシムライドキン

今月のMVPはMaxim Rydkinです。 彼は、 実行待ちのパイプラインが関連しなくなった場合に、それらを自動的にキャンセル する設定を開発しました 。 これは、GitLabに別のコミットをプッシュし、すぐに小さな編集を実行する場合に非常に便利です。 同時に、最初のコミットで処理を待機しているパイプラインはキャンセルされ、処理のための余分な時間とリソースは消費されず、2回目のコミットでパイプラインの結果をすばやく取得できます。 マキシム、ありがとう！

サービスデスク（EEP）

Service Deskは強力な新機能であり、GitLabインターフェイスから直接メールでチームとユーザーと通信できるようにします。 彼女の仕事には、追加のツールは必要ありません。 この機能は、ユーザーからのフィードバックを失わず、これらのユーザーの実際の問題を解決する機能に正確に取り組むのに役立ちます。

ユーザーは、バグレポート、機能のリクエスト、またはその他の電子メールフィードバックをGitLabプロジェクトに直接送信できます。 各通信は、新しいタスク（問題）になります。 チームメンバーは、GitLabのタスクにコメントするだけで、メールに返信できるようになります。

Service Deskの機能はGitLabに直接組み込まれているため、外部サービスとの統合をセットアップしたり、各リクエストを処理するときにさまざまなツールを切り替えたりする時間を無駄にする必要はありません。 これにより、ユーザーからのリクエストにより迅速に対応し、必要な更新を開発できます。

プロジェクト設定で機能を有効にするだけです。 このプロジェクトの一意の住所は自動的に作成されます。 ユーザーがこのアドレスに電子メールを送信するたびに、GitLabは対応するプロジェクトに新しい機密タスクを作成します。 チームメンバーが残したコメントは、返信レターでユーザーに送信されます。 ユーザーはこのようなメールに返信することもできます。 この場合、すべての通信がこのタスクのコメントに表示されます。

ヒント：ユーザーから要求された機能を実装するか、バグを修正する場合は、別のコメントにそれについて書いてください。

サービスデスクの詳細については、ドキュメントをご覧ください。

カナリア展開（EEP）

継続的デリバリーを実装する企業は、特定の展開戦略を選択する必要があります。 最も人気のある戦略の1つは、カナリア展開です。 彼らのポイントは、新しいバージョンが最初にインフラストラクチャのごく一部に展開されることです。 そして、カナリア？ むかしむかし、カナリアは炭鉱に運ばれ、メタンのレベルを決定しました。メタンが上昇すると、カナリアは死にます。 同様に、アプリケーションの新しいバージョンの動作がおかしい場合は、ごく一部のユーザーにしか影響しないため、変更を簡単に修正またはロールバックできます。

GitLab 9.1では、Kubernetesのキャンベリー展開戦略はすぐに利用できます。 Auto Deployを使用するプロジェクトは、この機能が既に実装されている更新済みのAuto Deployテンプレートに切り替えることができます。

展開パイプライン用のスクリプトを自分で作成する場合、またはこの機能の詳細を知りたい場合は、カナリア展開の段階を追加する方法に関するドキュメント記事が役立ちます。

パイプラインが進むにつれて、Deploy Boardsは、カナリアデプロイメントに使用されるインフラストラクチャの一部を明示的にマークします。

これにより、各環境および展開全体の状態に関する情報をすばやく取得できます。

バーンダウンチャート（EE）

GitLabは、開発プロセスを会計および管理するためのますます便利なツールと考えています。 このリリースでは、プロジェクトのタスクを完了するためのスケジュールを追加しました。 次のマイルストーンへの途中で、毎日完了したタスクの数が表示されます。 残っているタスクの数と、開いているタスクの総重量を確認できます。 この共有の変更のダイナミクスにより、期限にどれだけ収まるかがわかり、事前に必要な決定を下すことができます。

プロジェクトでは、開始日と終了日が設定されている各マイルストーンは、タスクを完了するための独自のスケジュールを自動的に取得します。 このグラフはマイルストーンページにあります。 特定の日付の未処理タスクの合計重量を表示するように切り替えることができます。 この機能が正しく機能するためには、タスクに適切な重みを割り当てます。 重みが0の開いているタスクは、開いているすべてのタスクの合計重量を増加させません。

グラフを追加して、チャンスをつかみ、ページ全体を再編集しました。 これで、GitLabの残りのページのインターフェイスの精神で、よりシンプルで便利になりました。

私たちのドキュメントでは、 タスクのスケジュールについて詳しく説明します 。

タグ保護（CE、EE）

gitを使用する一部のモデルでは、誰もがタグ（タグ）を作成および更新する権利を持っているわけではありません。 GitLab 9.1には、タグを作成または変更する機能を制限するためにタグを保護する機能が導入されています。

タグ保護はブランチ保護に非常に似ています。 この機能は、どのプロジェクトでも使用できます。 タグを作成できるユーザーのリストを制限したり、タグ名が対応する必要があるマスク（ワイルドカード）を構成したりできます。

タグ保護に関するすべての情報はドキュメントに記載されています。

最近の検索（CE、EE）

最近の検索を表示する便利なドロップダウンリストを検索バーに追加しました。 データはブラウザに保存されます。この機能は設定を必要としません。

検索履歴の仕組みの詳細については、ドキュメントを参照してください。

マージリクエストとタスク（CE、EE）のディスカッション

GitLabでは、diff-mergeリクエストのコード行をコメントアウトすることでディスカッションを開始できます。 議論は「決定可能」です。特定の結果になると、小さなタスクのように解決されたと見なすことができます。 バージョン9.1以降、ディスカッションはコードの行に添付する必要がなくなりました。メインのコメントストリームで直接ディスカッションを開始できます。

これは、マージ要求全体の内容について議論したいが、議論を解決するためにツールを使用する場合に非常に便利です。

このリリースでは、この原則をタスクのコメントにも適用しました。

問題の議論の意味は、自由な意見交換にあります。 そのため、タスクにディスカッションを追加することにしましたが、それらを解決済みとしてマークする機能は含めません。

これにより、コラボレーションにGitLabを使用するのがさらに便利になりますが、新しいアイデアを議論するプロセスが中断されることはありません。

コミットとスニペットも検討できるため、新しい機能が登場しました。

マージリクエストのディスカッションとタスクの詳細については、ドキュメントを参照してください。

マージリクエストの議論を解決

タスクでの議論

新しいタスク（CE、EE）の作成時にマージ要求を許可する

以前は、新しいタスクを作成してマージ要求のすべてのディスカッションを解決することが可能でした 。そのため、これらのディスカッションは失われず、新しいタスクに転送されました。

このリリースでは、この機能の柔軟性を拡張しています：解決のために特定のディスカッションを選択し、新しいタスクに転送できるようになりました。これにより、いくつかの問題を後回しにして、このマージリクエストに重要な問題の解決に集中できます。

新しいタスクを作成してマージリクエストのディスカッションを解決する方法の詳細については、ドキュメントを参照してください 。

Microsoft Teams（CE、EE）との統合

GitLabを可能な限り最も完成度の高いツールにして、アイデアからリリースまで可能な限り高速にすることを支援します。 これには、Mattermost、Slack、最近登場したMicrosoft Teamsなど、アイデアが形成され議論されているプラ​​ットフォームとの統合が必要です。

Microsoft Teamsと統合する最初のステップは、 Office 365コネクタを使用してMicrosoft TeamsルームにGitLabイベントアラートを追加する機能でした。

つまり、リポジトリにプッシュするとき、タスクを作成または更新するとき、またはリクエストをマージするときにTeamsで通知を受信できるようになりました。 また、継続的統合パイプライン（CIパイプライン）の実行結果をチームに渡すこともできます。

アラートはカードの形で表示され、実行されたアクションのすべての詳細と、GitLabページへの対応するリンクがより完全な情報とともに表示されます。

Microsoft Teamsとの統合に関する詳細については、ドキュメントを参照してください 。

ファイルテンプレート（CE、EE）の簡略化された作業

GitLabは長い間ファイルテンプレートを作成できました。 たとえば、継続的統合を構成するには、 .gitlab-ci.ymlファイルテンプレートを使用できます。 GitLab 9.1は、テンプレートの使用をさらに簡単にします。

これで、ファイルを作成または編集するときに、GitLabは以下のスクリーンショットに示すように、すべてのタイプのテンプレートのリストを表示します。 ファイルテンプレートを変更すると、エディターの内容が完全に置き換えられますが、このアクションは情報を失うことなくいつでも元に戻すことができます。

タスク名の自動更新（CE、EE）

多数のユーザーがGitLabを使用すると、データは常に更新されます。 このリリース以降、タスク名はページを更新する必要なく自動的に更新されます。

このタイプの機能は、タスクページの多くの要素、およびGitLab全体を要求します。 これは将来のリリースで行う予定です。

アプリケーション監視の機能強化（CE、EE）

アプリケーションの監視プロセスにいくつかの小さな変更が加えられ、機能が改善され、作業が簡単になりました。 たとえば、美しい起動画面、パフォーマンスグラフ、デバッグ用の追加情報が表示されました。

GitLab 9.1のその他の改善点

マージ要求承認（EE）設定を簡素化する

承認機能を使用すると、マージリクエストのユーザーまたはグループのリストを作成し、このリストの特定の人数が確認するまでそれをブロックできます。 このアプローチは、多くの組織におけるコードレビュープロセスの重要な部分です。 このリリースでは、プロジェクト設定インターフェイスが簡素化され、その機能をさらに拡張するための基盤が構築されました。

マージリクエストの承認に関する詳細については、ドキュメントを参照してください 。

災害復旧の改善（アルファ）（EEP）

GitLab 9.1には、GitLab 9.0と共にリリースされたアルファ版の災害復旧機能の改善が含まれています。

まず、 Geoで作業するプロセスを簡素化しました 。 第二に、 Geoの構成に必要なステップの数を減らしました。

3番目に、ディスクに保存されている次のタイプのファイルのレプリケーションのサポートを追加しました：タスク、マージ要求、解説アプリケーション、ユーザー、グループ、プロジェクトのアバター。 将来のリリースでは、 災害復旧を改善するために積極的な作業を継続する予定です。

災害復旧のアルファ版に関する詳細については、ドキュメントを参照してください 。

コミットビュータブ（CE、EE）にパイプラインミニスキームを追加する

コミット表示タブのシステム情報ウィンドウにパイプラインのミニスキームが表示されるようになりました。 以前は、マージリクエストを表示する場合にのみ使用できました。

コンベアに関する詳細は、ドキュメントをご覧ください。

パイプライン成功通知はデフォルトで無効になっています（CE、EE）

冗長な情報の流れを減らし、ユーザーがアラートをより細かく制御できるようにするために、GitLab 9.1のコンベヤーアラートの原則を変更しました。 パイプライン成功アラートはデフォルトで無効になりました。 それらを接続するには、通知レベルを「カスタム」に変更し、「 Successful pipeline



を選択する必要があります。 また、このアプローチでは、パイプラインを立ち上げたユーザーのみが手紙を受け取ることに注意してください。

コンベアアラートの詳細については、ドキュメントを参照してください 。

システムノートアイコン（CE、EE）

GitLabに新しい機能が追加されると、タスクとマージリクエストのディスカッションで行われた変更に関する情報を時系列に表示する必要性が高まります。

このリリースでは、システムノートの横にアイコンが追加されました。これにより、システムアクションとユーザーコメントを簡単に区別したり、オブジェクトの開発プロセスを評価したりすることができます。

使用統計（CE、EE）

GitLab Community Editionでは 、バージョン8.10以降、GitLab Enterprise Editionでこれまで利用可能であった使用統計機能が追加されました。

その助けを借りて、今後数か月で、インスタンスのユーザーのアクティビティを他のすべてのGitLabユーザーと比較して評価できるようになります。 対応するタスク 、およびそれが出現したタスクの詳細 。 統計は毎週送信されます。admin > cohortsで正確な数値を確認できます。 admin > settingsから統計の収集への参加を拒否できます 。

統計の収集に関する詳細については、ドキュメントをご覧ください。

タスクボードのフォーカスモード（EE）

Issue Boardsは、開発者チームが関与するタスクを計画および管理するための優れたツールです。 これにより、開発のさまざまな段階間でのタスクの動きを追跡できます。

このリリースでは、タスクボードにフォーカスモードが導入され、ナビゲーションインターフェイスが非表示になります。

このモードは、多くの人が一緒に作業しながら1つの画面を見る場合に役立ちます。 つまり、まず、物理的に1か所に配置されているチームを対象としています。 タスクボードウィンドウの右上隅にあるボタンをクリックして、オン/オフを切り替えます。

タスクボードの詳細については、ドキュメントを参照してください 。

複数のDockerイメージプロジェクト（CE、EE）

状況によっては、開発者は同じコードベースに基づいて複数のコンテナを作成できます。 これは、コンテナを早い段階で作成し、後の段階で使用するタブがある場合に発生する可能性があります。 または、異なるバージョンの依存関係をパッケージ化する場合。

GitLab 9.1では、コンテナレジストリは各プロジェクトの複数の画像名をサポートし、複数のプロジェクトコンテナを簡単に保存できます。

たとえば、ストレージは同時にregistry.example.com/group/project/core:latest



と

registry.example.com/group/project/dependencies:latest

アンドレ・ゲデスの素晴らしい貢献に感謝します！

コンテナレジストリの詳細については、ドキュメントをご覧ください。

不要なコンベヤーの自動キャンセル（CE、EE）

短期間に多数のコミットがある場合、1つのブランチのコミットに対する複数のパイプラインがキューイングできます。 以前は、パイプラインは主に先着順で処理されていたため、パイプラインは既に置き換えられていても、主に古いコミットに対して実行されていました。 これにより、現在のブランチがテストされているかどうかの理解が遅れ、CIランナーを使用すると効率が悪くなりました。

GitLab 9.1のリリースでは、古いコミット（つまり、非HEADコミット）のパイプライン

同じブランチで新しいパイプラインが開始されると、自動的にキャンセルできます。 これにより、キューをより効率的に処理し、新しいメイン（HEAD）パイプラインを簡単に開始できます。

まだ起動していないスタンバイ専用モードのコンベヤは、自動的にキャンセルされます。 新しいプッシュが到着する前に起動されたコンベヤは、通常実行されるまで動作し続けます。

この機能を追加する場合は、CI / CD Pipelinesプロジェクトの設定で有効にします。 将来のリリースでは、自動キャンセルは自動的に有効になります。

追加のパイプラインの自動キャンセルの詳細については、ドキュメントをご覧ください。

スケジュールされたパイプライントリガー（CE、EE）

GitLab 9.1のリリースでは、定期的に実行するパイプラインスケジューリングのアルファサポートが追加されました。 たとえば、毎日のパイプラインを実行して、外部の依存関係をテストしたり、夜間にテストしたりできます。 スケジュールされたパイプラインを構成するには、パイプライントリガー（パイプライントリガー）を追加して編集し、 Schedule trigger



をオンにしSchedule trigger



。 cron形式を使用して 、スケジュールを設定します。

ドキュメントのスケジュールされたパイプライントリガーについて読んでください。

大きなログ（CE、EE）を持つジョブのサポートの改善

生産性の向上に焦点を当て、大規模なタスクのログ処理を最適化しました。 GitLab 9.1は、タスクを表示するときに最後の500 KBのログのみを表示するようになりました。これにより、ページの応答時間とスループットが大幅に短縮されます。

継続的インテグレーション（CI）を使用したジョブのエラーは常に終わり近くで発生するため、多くの場合、ログ全体を送信して表示する必要はありません。 これは、タスクログだけで60 MBを占有する可能性があるAndroidのような大規模プロジェクトでは特に重要です。 さらに分析が必要な場合は、[ ダウンロード ]ボタンをクリックしてログ全体をいつでもダウンロードできます。

高度な自動展開（CE、EE）

カナリアデプロイメントのサポートとともに、 Auto Deployに 2つの重要な変更を加えました。 最初に、デフォルトでPostgreSQLを自動的に提供することにより、データベースを必要とするアプリケーションのアルファサポートを追加しました。 変数を使用して権限を設定し、データベースの名前を変更するか、 DISABLE_POSTGRES



変数でyes



をマークしてPostgresを無効にすることができます。 また、実験としてプライベートプロジェクトのサポートを追加しました。これにより、KubernetesはGitLab Container Registryからアプリケーションコンテナーを認証およびダウンロードできます。

プライベートプロジェクトの詳細とPostgreSQL自動展開データベースのサポート、および重要な制限は、ドキュメントに記載されています。

パイプラインのリストが自動的に更新されるようになりました（CE、EE）

私たちのコミットメントの1つは、GitLabユーザーの使用が可能な限り最高のエクスペリエンスを確実に得られるようにすることです。 これを行うために、パイプラインの概要ページを変更しました。現在は自動的に更新されます。 将来のリリースでは、ワークフローの追加モデルに引き続き取り組みます。これにより、手動で更新する必要性が絶えずなくなります。

コンベアの詳細については、ドキュメントをご覧ください。

Elasticsearch Enhancements（EE）

GitLab 9.1 EEでは、実験的なリポジトリインデクサーが導入されています 。 完全に書き直されたため、4倍高速になりました。 有効にするには、管理パネルを確認してください：

フィードバックをお送りください-いくつかのリリースを通じて、このインデクサーをデフォルトにしたいと考えています。 さらに、管理者とバリデーターは、Elasticsearchが有効になり、検索結果が再び強調表示されるときにグローバル検索を使用できるようになります。

Elasticsearchの詳細については、ドキュメントをご覧ください。

GitLab Runner 9.1の変更（CE、EE）

また、GitLabの最新バージョンでは、GitLab Runner 9.1をリリースしました。

最も興味深い変更

• ランナースイッチを使用した検証コマンドの展開（ マージ要求 ）
• log_levelオプション（ merge request ）をconfig.tomlに追加しました
• キャッシュコンテナー検出の回帰（ マージリクエスト ）を修正
• ドッカーメトリックプロバイダーのクリーニングと名前変更を追加（ マージリクエスト ）
• Docker作成時間のヒストグラムメトリックを追加（ マージリクエスト ）

CHANGELOG GitLab Runnerですべての変更のリストを見つけることができます。

GitLabランナーの詳細については、ドキュメントをご覧ください。

パフォーマンスの改善（CE、EE）

私たちにとって、GitLabの高速化は常に最優先事項です。 毎月、パフォーマンスを向上させ、GitLabをより高速で信頼性の高いものにします。 これはGitLab CEおよびEEだけでなく、すべてのユーザーのGitLab.comの速度と信頼性が向上します。

バージョンGitLab 9.1では、 プロジェクトのリストとマージリクエストの表示に必要な時間をほぼ半減し、 入力分析の可用性を向上させ、 GitHubプロジェクトのインポートをより速く、より信頼性の高いものにし、GitLabの更新に向けていくつかの大きな一歩を踏み出しました。

GitLab 9.1のパフォーマンス改善の全リストをご覧ください。 さらに、バージョン9.2で計画されている膨大な数のパフォーマンス改善タスクが既にあります。

GitLabパフォーマンスモニタリングの詳細については、ドキュメントをご覧ください。

Omnibusパッケージの機能強化（CE、EE）

SUSE Linux Enterprise Server 12。

GitLabがSUSE Linux Enterprise Server 12.2で利用可能になりました。

インストール手順をお読みください 。

GitLab Mattermost 3.7.3

GitLab 9.1には、 Mattermost 3.7.3が含まれています。これは、Web、PC、携帯電話でメッセージをアーカイブおよび検索する機能を提供するSlackの代替オープンソースです。 今月の改善では、iOSおよびAndroid用の次世代ベータ版アプリケーション、新しいコマンドラインインターフェイスへの統合などを考慮しています。

このバージョンにはセキュリティ更新プログラムがあるため、更新することをお勧めします。

Mattermost 3.7.3は、GitLabバージョン9.0.4ですでに登場しています。 GitLab 9.0.4以降を使用している人は全員、パッチを受け取っているはずです。

その他の改善

• GitLabにはGit 2.11（ チケット ）が付属しています。
• Terraform設定を使用して、GitLabインスタンスをGoogleCompute Engine（GCE）（ ticket ）で実行できるようになりました。 gitlab-runner起動サポートの開発が進行中です
  
  （ チケット ）。
• Google Cloud Storage（Google Cloud Storage）がContainer Registry（ ticket ）のバックエンドとして使用できるようになりました。

Omnibus GitLabの詳細については、ドキュメントをご覧ください。

サポートの終了

Ubuntu 12.04パッケージ

GitLab 9.1は、Ubuntu 12.04が4月28日に存在しなくなったため、Ubuntu 12.04パッケージをサポートする最新リリースです。 GitLab 9.2は、Ubuntu 14.04および16.04で引き続き利用できます。

2017年5月22日まで。

OpenSUSE 13.2

GitLab 9.1は、今年の終わりにEOL（EOL）に達したOpenSUSE 13.2パッケージをサポートする最新リリースにもなります。 GitLab 9.2はOpenSUSE 42.1で利用可能になります。

---

詳細なリリースノートと更新/インストール手順は、元の英語の投稿で見つけることができます： https : //about.gitlab.com/2017/04/22/gitlab-9-1-released/

英語からの翻訳は、翻訳チーム「Brain and Partners」、 http：//nadmosq.ruによって行われました。 Nick_volynkin 、 rishavant 、およびsgnl_05が翻訳に取り組みました。