GitLab 9.0：サブグループとデプロイボードがリリースされました

バージョン8.0のリリースから 18か月後に、最近GitLab 9.0をリリースしました 。 この間、 GitLabに多くの重要な変更を加え 、毎月22日に新しいバージョンをリリースしました。 8.0から出てきたものを簡単にまとめ、バージョン9の新しい機能と古い機能を比較してみましょう。 または、9.0に登場した機能に移動できます。

アイデアから生産まで

最新のリリースにより、GitLabは製品開発に対するチームのアプローチを変更しました。 ほんの数分で、コンテナスケジューラにGitLabを展開し、自動的に展開されたレビューアプリでCI / CDを追加し、ChatOpsを使用してサイクルタイムを分析できます。 バージョン9.0では、展開ボードで展開を表示し、Prometheusを使用してアプリケーションのパフォーマンスを追跡できます。 マスタープランに基づいて、GitLab 9.0は開発者向けの膨大なDevOpsツールセットを提供します。 仕組みを見てみましょう。

使いやすさとデザイン

バージョン8.0では、UIのほぼすべての要素を変更し、使いやすさを大幅に改善することにより、GitLabインターフェイスを更新しました（数か月前にロゴを更新しました）。使いやすさの改善、小さなCSSの調整からメインUXスレッドの変更まで、すべての分野で主な問題点を見つけて処理します。 各リリース8.xでは、徐々に設計を開発しました。 また、GitLab 9.0では、 全体、グループ、およびプロジェクトのナビゲーションを簡素化する点で大きな進歩を遂げました。 これは、GitLab機能セットがより強力になっている重要な変更点です。

UXを改善し続けるために、GitLabの将来に影響を与えることができる研究パネルがあります。 このグループに参加することで、あなたは最初に新しい機能を試してみることができ、製品の改善においてそれらについてのあなたの考えを考慮に入れます。

私たちの研究チームに参加してください 。

デジタルワークコラボレーション

GitLabは、デジタルコラボレーションのためのチーム作りを支援します。 GitLabでのコラボレーションの基盤である問題に多くの変更を加えました。 たとえば、タスクの重み（ 8.3 ）、それらをマージ要求にリンクする（ 8.3 ）、タスクを別のプロジェクトに移動する（ 8.6 ）、強力なフィルターおよび検索インターフェース（ 8.16 ）などです。 また、さまざまなステージ（GitLab言語の「リスト」）を使用してタスクのフローを制御するためのシンプルなメカニズムを提供する発行ボード（ 8.11 ）もリリースしました。 GitLab 9.0はボードをさらに改善し続け、マイルストーンとの統合を改善します。

GitLab 9.0でサブグループを導入できることを嬉しく思います。これは、GitLabでのコラボレーションを改善するためのもう1つの大きなステップです。 グループ内のグループのこの強力な新しいパラダイムは、多数の異なる部門を持つ大規模な組織であっても、チームベースおよびチームファーストの原則に基づいたチームワークを支援します。 私たちの使命は、 誰もが貢献できるようにすることです 。 バージョン9.0は、どこにいてもプロセスを簡素化するのに役立ちます。そのため、実際に組織内の全員が共通のタスクに貢献できるのです。

レビューとコードコラボレーション

パイプラインの正常な実行後のマージ（ 8.3 ）、差分（コードの差分、 8.4、8.5、8.7、8.10、8.15 ）、競合エディター（ 8.11、8.13 ）、マージリクエストのバージョン（ 8.12 ）、ディスカッションが解決されるまでマージをブロック（ 8.14 ）、権限の切り替え（ 8.16 ）、およびスカッシュとマージ（ 8.17 ）。 これらおよびその他の機能の多くには、マージ要求ウィジェットが含まれています。 そのため、GitLab 9.0では、設計を改訂して、相互作用する既存および将来の多くの機能に合わせました。

継続的インテグレーション

バージョン8.0以降 、継続的統合（CI）がGitLabに追加されました。 その後、新しいCI機能（ 8.4 ）がAPIに追加され、パイプラインイベントがWebフック（ 8.11 ）を介して利用可能になりました。 また、パイプラインはマージ要求（ 8.11、8.17 ）およびコミット（ 8.13 ）に統合され、パイプラインのグラフィカル表示（ 8.11 ）が追加されました。 8.10から8.17のすべてのリリースで、 GitLabランナーの改善が追加されました。 レビューアプリ（ 8.12、8.13、8.14 ）と自動デプロイ（ 8.15 ）を起動して、自動生成された環境にコードを自動的にデプロイしました。 また、GitLab 9.0のリリースに伴い、deploy boardを起動します。これにより、さまざまなサーバーへのアプリケーションの展開を監視できます。

分析と監視

GitLabは、コードと開発プロセスを分析および監視するためのツールを提供します。 バージョン（ 8.3 ）では、開発へのプロジェクト参加者の貢献度のマッピングと、開発サイクルの分析（ 8.12、8.13、8.14 ）が追加されました。 時間追跡機能が追加されました（ 8.14、8.16 ）。 バージョン8.16および8.17では、オープンソースのPrometheusが追加され、Prometheusコンソールを介してGitLabインスタンスを実行しているサーバーを監視できるようになりました。 GitLab 9.0では、GitLabユーザーインターフェイスに組み込まれたPrometheusベースの統合監視が追加されました。

謝辞

多くのタスクを作成してコメントし、ソースコードを直接追加するコミュニティに感謝します。 バージョン9.0では、コミュニティメンバーによって130以上のマージ要求が作成され 、その多くがプロジェクトの開発に大きく貢献しました 。

オープンソースプロジェクトであるGitLab CEでは、 47,000件を超えるコミットが既に行われています。これは、バージョン8.1でのコミット数の2倍-20,000です。 現在、 1,500人以上の参加者がGitLabの開発に貢献しています。 ありがとう

成長

私たちのチームもこの期間に大幅に成長しました。 バージョン8.0のリリース時点では、7か国の25人未満がGitLabで働いていました。 今日、37か国から150人以上が参加しています。 この成長により、 コミュニティエディション（CE）、エンタープライズエディションスターター（EES）、エンタープライズエディションプレミアム（EEP）の 3つの異なるバージョンのGitLabをリリースすることができました。

ユニークなプラットフォーム

最近、アプリケーションライフサイクル管理（ALM）ツールは、単一の統合アプローチに進化しました。 GitLabはこの開発ベクトルを完全にサポートしているため、このバージョンでは、 計画どおりにデフォルトで監視機能が提供されます。 これ以降、GitLabからアプリケーションを直接開発、コードの作成、ビルド、デプロイ、および監視できます。

GitLabは、単一のインターフェイスとデータウェアハウスを備えた完全な自己完結型のアプリケーションライフサイクル管理ツールです。 この統合されたアプローチのおかげで、開発時間が短縮され（サイクルの分析を使用して測定）、効率が向上し、開発プロセスが正規化されます。

バージョン9.0をご利用ください！

登録してリリースのプレゼンテーションをご覧ください

GitLab 9.0リリースミーティング

GitLab 9.0マイルストーンは、サンフランシスコ、デンバー、ボストン、アムステルダム、ロンドン、ニューオーリンズで開催されます。

今すぐ参加しよう！

今月のMVPはJacopo Beschiです。

彼のおかげで、以前に割り当てられた「完了」ステータスをtodoリスト項目から削除することが可能になりました。これにより、誤って完了とマークしたtodoタスクを返すことができ、その結果、開発の生産性が向上します。 ありがとう、jacopo

サブグループ（CE、EE）

GitLabを使用することは、アイデアからリリースまで、プロジェクトのすべての段階でコードを共同作業する最も簡単な方法でした。 また、個別のリポジトリを備えた開発チームの階層に基づいたコラボレーションの実装に関するユーザーからのリクエストを受け取りました。 Gitlab 9.0では、グループ内のグループ、つまり「サブグループ」の作成をサポートするGitLabグループの新しいバージョンを導入できてうれしく思います。

階層の任意のレベルのサブグループは、本格的なGitLabグループであり、複数のプロジェクト（リポジトリ）に属することができます。 したがって、グループの新しいバージョンでは、最大20レベルのネストの階層を作成できます。

この例では、組織（ gitlab-nested



グループで表されます）には、設計チーム、バックエンドチーム、およびフロントエンドチームが含まgitlab-nested



ます。各チームには、 gitlab-nested



含まれる独自のグループがあります。 design



およびbackend



グループには独自のサブグループがあります。

グループの機能のさらなる開発の現在のプロセスを見て、 ここにあなたの願いを残すことができます。

サブグループに関する詳細なドキュメント

ボードの展開（EEP）

GitLabは強力なCI / CDシステムをサポートしています。このシステムでは、GitLab.comだけでもプロジェクトに1,000人以上のランナーがいます。 それらで実行されているパイプラインは、ソフトウェアをコンパイルおよびコンパイルし、自動テストを実行し、レビューアプリを作成し、ステージングおよびプロダクションにデプロイすることさえできます。 以前は、環境の更新が成功したかどうかを示す展開レポートが作成されました。 しかし、さらに詳細が必要な場合はどうでしょうか？ または、たとえば、すべての環境のすべての展開に関する情報を表示するための単一のインターフェースですか？ 大規模な組織では、これらの質問に対する回答が特に重要になります。

GitLab 9.0のリリースに伴い、Kubernetesを使用する環境向けのDeploy Boardsを紹介します。 [パイプライン]-> [環境]タブには、各ポッドまでの各環境の現在の状態と展開ステータスに関する情報を表示する単一のインターフェイスがあります。 開発者や他のチームメンバーは、Kubernetesにアクセスする必要なく、使い慣れた開発環境で各ポッドの進行状況と展開ステータスを個別に表示できます。

ローンチを記念して、Enterprise Edition StarterユーザーはDeploy Boardsをバージョン9.0で無料で利用できます。

ボードのドキュメントを展開する

エクスポートタスク（EES）

GitLabは既にフィルタリングとタスク検索機能を実装しています。 ただし、外部で使用するタスクのリストを取得する必要がある場合があります。 たとえば、オフライン分析や、GitLabを使用しないチームとの共同作業用です。 バージョン9.0 EESでは、タスク表示ページの画面の右上隅にあるダウンロードボタンをクリックすると、CSV形式のタスクのリストが記載された電子メールが届きます。

この機能はタスク表示ウィンドウに直接統合されているため、フィルタリングおよび検索メカニズムを使用して、必要なタスクのリストをダウンロードできます。 このようなリクエストの処理とメッセージの送信はバックグラウンドで非同期に行われるため、リクエストの確認後すぐにGitLabを使用し続けることができます。

タスクのエクスポートの詳細については、 こちらをご覧ください。

統合モニタリング（CE、EE）

堅牢な監視インフラストラクチャを持つことは、アプリケーションを正常に管理するための鍵です。 変更に迅速に対応し、その結果を追跡し、問題が発生した場合にデバッグすることができます。 ただし、このようなインフラストラクチャの作成は、特にテスト環境では特に優先順位が低くなります。 その結果、監視システムがプロジェクトに統合されていない場合が頻繁にあります。

GitLab 9.0のリリースにより、CI / CDパイプラインおよびソースコードリポジトリに完全に統合された最初の監視システムを発表できることを誇りに思います。 これ以降、ステージングアプリやレビューアプリなどのGitLabテスト開発環境は、最終的な「戦闘」環境と同じ監視テクノロジーを使用します。 このシステムは、 Prometheusを使用して実装されます。

このバージョンは、各Kubernetes環境で実行されているアプリケーションによるプロセッサおよびメモリリソースの使用を監視しますが、これはほんの始まりに過ぎません。 近い将来、パフォーマンスへのマージの影響の評価、分析されたより広範なデータのサポート、および展開ボードへの監視データの転送を追加する予定です。

ここで GitLab監視システムのさらなる開発の議論に参加してください 。

Prometheusを使用したプロジェクト統合ドキュメント

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

いつものように、GitLabのパフォーマンスを改善するために一生懸命取り組んでいます。 バージョン9.0では、システムの大幅な高速化を目的とした多くの変更が導入されています。 Elasticsearch（ES）のGitLab EE 9.0には、ES 5.1のサポートだけでなく、多くの修正が含まれています。 クラウドネイティブの哲学に従って、 AWSホストおよびHTTPS Elasticsearchクラスターのサポートを追加しました。 プライマリインデックスプロセスの改善により、GitLab EEでの大規模プロジェクトの作業が加速されます。 さらに、リポジトリのインデックス作成プロセスにいくつかの小さな変更が加えられました。

作者とタスクの実行者のための検索アルゴリズムは改良されました 、そして、 不要な質問は取り除かれました 。 これらの変更は、ほとんどのユーザーに表示されるはずです。なぜなら、自分に割り当てられたタスクとマージ要求を表示することはかなり一般的な手順だからです。 GitLab.comでは、これらの変更により、すでにトランザクション時間が大幅に短縮されています。

バージョン9.0でのパフォーマンス改善の全リストをご覧ください。今後のリリースでのさらなる改善を追跡することを忘れないでください。 GitLabは、特に大規模プロジェクトを扱う場合に、より速く成長し続けています。

GitLab.comは、数十万人のユーザーを抱えるGitLab EEの「単なる」大規模な実装であることをご存知ですか？ これにより、GitLab EEで作業できるスケールを測定でき、前述のパフォーマンスの改善により、GitLab.comの速度と信頼性が大幅に向上します。

問題ダッシュボードのトランザクションタイミングが大幅に低下

マージリクエストダッシュボードのトランザクションタイミングが大幅に低下

データベース負荷分散（EE）

データベースクエリの負荷を分散すると、クエリの量とサーバーの負荷を分散できます。 原則として、これにはpgpoolなどのサードパーティソフトウェアの使用が必要です。 バージョン9.0以降、GitLab Enterprise EditionはPostgreSQLを使用する場合のクエリ配布をサポートしています。

このアプローチには、たとえば、メインデータベースの負荷とメモリ使用量の削減、クエリへの応答時間の短縮など、多くの利点があります。 さらに、負荷分散により、過度に要求の厳しいクエリが他のサーバーのデータベースクエリに影響を与えないため、GitLabの機能に悪影響を及ぼす可能性が低くなります。

GitLabクエリバランサーは、データベースの障害にも対応します。 メインデータベースが応答しない場合、またはセカンダリへの切り替えがある場合、バランサーは短い休止の後に操作を繰り返します。 また、セカンダリデータベースが応答しない場合、アロケータは再び使用可能になるまでそれらを無視します。 このようなシステムを最も透過的に機能させるには、各ホストにクエリバランサー（HAProxyなど）を使用する必要があります。

クエリ配布システムを使用する場合、コピー遅延の問題があるという事実に注意を払う価値があります。 たとえば、セカンダリデータベースからの書き込みおよび後続の読み取りの際に、このデータベースにまだデータがない状況が発生する可能性があります。 この問題を解決する1つの方法は、同期コピーを使用することです。 ただし、この方法では、コピーの遅延によりリクエストの処理時間が大幅に増加する可能性があります。 さらに、何らかの理由でデータのコピーが使用できなくなった場合、システム全体が停止する可能性があります。

この問題を解決するために、「スティッキーセッション」アプローチが使用されます。ユーザーがメインデータベースでレコードを開始すると、このユーザーのセッションはメインデータベースを使用し続けます。 これは、タイムアウトが期限切れになるまで（30秒）、または記録されたデータがすべてのセカンダリベースで利用可能になるまで続きます。

データベースバランサーのセットアップの詳細については、 データベース負荷分散のドキュメントを参照してください。

更新されたナビゲーション（CE、EE）

GitLabでは、ほとんどのビジネスプロセス（製品開発だけでなく）はGitLab.com自体で行われます。 したがって、ナビゲーションの重要性を正確に把握しています。 特に、毎日数時間GitLabを使用しているユーザーにとって、毎日のタスクでスムーズで直感的で効果的なものにしたいと考えています。

ナビゲーションデザインはこの目標を達成するための鍵であるため、9.0ではインターフェイスを変更し、デザイナーからのベストプラクティスとユーザーフィードバックを結び付けました。 一見、何も変わっていません。 これは特別です。 すでにうまく機能していたものを綿密に分析し、問題のある領域のみを変更しました。

ナビゲーションメニューの1番目と2番目のレベルのタブを再グループ化しました（場合によってはマージして名前を変更しました）。 [アクティビティ]タブが[プロジェクト]タブにネストされました。 リポジトリ、タスク、マージリクエスト、およびパイプラインのメインタブは、「アイデアからプロダクションへ」という意味で、それぞれ左から右に配置されています。 「グラフ」タブの第2レベルのタブは、再グループ化されて他の場所に移動しました。 分析からのデータと希望を使用して、各メニュー項目の場所を決定しました。 変更の詳細については、こちらをご覧ください。

もう1つの重要な変更点は、ポップアップサイドバーです。 左上にある、あまり目立たないドロップダウンメニューに置き換えられました。これは、画面コンテンツの大部分をカバーしていません。 以前は、設定にドロップダウンメニューを使用していました。プロジェクトまたはグループのページの右上にある歯車をクリックすると表示されます。 これで、設定がタブ付きナビゲーションインターフェイスに移動し、調和がとれ、使用が簡素化されました。

9.0では、プロジェクトビューの構成設定を簡素化したため、各プロジェクトの「ホームページ」に表示するもの（ファイルとREADMEまたは現在のアクティビティのリスト）を選択できるようになりました。 （これは、表示しているすべてのプロジェクトに適用されるプロファイル設定です。）最初のオプションはデフォルトで使用されます。 以前は、デフォルトではREADMEのみが表示されていましたが、新規ユーザーと既存ユーザーの両方に役立つものが必要でした。 そのため、フィードバックとユーザー調査を調査し、このオプションに決めました。

また、右上の[ +



]ボタンをクリックするだけで、新しいプロジェクトを迅速に作成する機会を返しました。

ボードリストのタスクの順序を変更する（CE、EE）

Issue Boardsは、さまざまな段階（GitLabの「リスト」）を移動するタスクを管理して、アイデアから生産にすばやく移行するための優れた方法です。 しかし、ユーザーは同じリスト内であってもタスクを並べ替えたり優先順位を付けたいことがよくあります。 バージョン9.0では、簡単なドラッグアンドドロップを使用して、タスクボードのリスト内のタスクの順序を変更できます。

Community Editionの発行ボードの詳細については、ドキュメントをご覧ください 。

マイルストーンボード（EES）

GitLabタスクボードを使用すると、1つのマイルストーンでタスクグループを管理できますが、そのたびに関連するマイルストーンフィルターを選択する必要があります。 GitLab 9.0 EESでは、特定のマイルストーンに関連するタスクボードを作成できます。 これにより、個々のマイルストーンに固有のボードを作成できます。

新しいマイルストーンごとにタスクを計画および実行するため、新しいボードが役立つと考えています。 これにより、マイルストーンを簡単に切り替えることができ、同時に、以前に完了したマイルストーンを保存して確認することができます。

エンタープライズエディションの発行ボードの詳細については、ドキュメントを参照してください 。

API v4（CE、EE）

APIは、タスクの自動化とGitLabの管理に最適なツールです。 GitLabをプロジェクトの最初から最後までより良い開発環境にするために毎月追加する新しい機能をサポートするように、APIを絶えず改善しています。

継続的な反復により、既存のAPIにいくつかの矛盾が生じています。 このリリースでは、APIの4番目のバージョンを紹介します。 私たちは、RESTful API標準により一貫性をもたせ、準拠させようとしました。

APIの3番目のバージョンは2017年8月までしかサポートしません。このバージョンを使用して、アプリケーションに必要なすべての変更を加えることをお勧めします。

バージョン4の変更点を確認して、違いを確認してください。

災害復旧（アルファ）（EEP）

会社の規模に関係なく、自然災害や人的要因に対するインフラストラクチャの回復力を確認する必要があります。 このタスクのベストプラクティスの1つは、異なる場所にある少なくとも2つのサーバー（1つはメイン、1つはセカンダリ）にデータを保存することです。 これは、ダウンタイムとデータ損失のリスクを減らすために実装する必要があります。 GitLabに組み込まれているディザスターリカバリーの多くのリクエストを受け取りました。 今日、私たちはそのサポートに向けた最初のステップを表しています。

GitLab 8.5では、GitLabにGeoが付属しています。 これは、メインインスタンスをミラーリングする1つ以上の追加のGitLabインスタンスを開始できる機能です。 Geoの主な目標はgit fetch



プロジェクトのクローン作成とgit fetch



を劇的に高速化することです。 Geoはこのシナリオに完全に対応しますが、障害を完全にサポートするためにこのテクノロジーを使用しないという1つの欠点があります。ディスクに保存されたファイルは複製されません。

この欠点の修正に積極的に取り組んでおり、GitLab 9.0では、災害復旧スクリプトのサポートの第1段階をリリースしています。 このリリースでは、Geoにいくつかの重要な変更が加えられました。

• LFSを使用する場合、LFSオブジェクトは追加のノードに自動的に複製されます（ マージ要求 ）。
• これで、すべてのファイルのダウンロードがデータベースに書き込まれます（ マージ要求 ）。
  
  これにより、後続の反復でこれらのファイルを複製できます。
• リポジトリを自動的に埋めるための新しいプロセスが登場しました
  
  （ マージ要求 ）。
• これで、ユーザーインターフェイスで追加ノードを無効にできます。
• それまでの間、上記のすべての機能はアルファ版のみにあります。Geoの主な機能は 、長距離にわたるプロジェクトのクローン作成と受信に使用されますが、商用利用に適しています（本番対応）。

ドキュメントには、災害復旧のアルファ版を有効にする方法が記載されています。

GitLab Geoの一部として、すべてのEnterprise Edition Premiumユーザーが災害復旧を利用できます。

注：GitLab 9.0でのPostgreSQLの更新のおかげで、GitLab Geo 8.xはGitLab Geo 9.0と互換性がなくなったため、手動で更新する必要があります。 すでにGeoを使用している場合は、GitLab 9.0にアップグレードする前にアップグレードの手順をお読みください 。

---

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

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