GitLab 9.2リリース：複数のタスクエグゼキューター、スケジュールされたパイプライン、ローカリゼーション、災害復旧アルファ

GitLabは、チームの規模やメンバーの場所に関係なく、各プロジェクト参加者が貢献できるように設計されています。

多くの場合、製品開発のプロセス中に、フロントエンドとバックエンドの開発者、インターフェース設計者、テスター、製品マネージャーなど、複数の人が同じタスクに取り組みます。 GitLab 9.2のリリースにより、それらすべてを1つのタスクの実行者に任命できるようになりました 。これにより、共同開発のプロセスが簡素化され、共通の責任範囲を視覚的に表示できるようになります。

バージョン9.2は、GitLabローカリゼーションプロセスの始まりでもあります。CycleAnalytics はスペイン語とドイツ語で利用可能になりました 。 GitLabのローカライズは将来のリリースでも継続されるため、母国語に関係なく全員が貢献できます。

さらに、開発者はCI / CDパイプラインのランタイムをより詳細に制御できるようになりました。 パイプラインの実行をスケジュールできるようになりました。これにより、夜間のアセンブリ、メンテナンス、外部依存関係の確認などの定期的なタスクを自動化できます。

ミーティングにご招待します！

今月のMVP- 道助伸也

Dosuken は、パイプラインインターフェイスに 高度な検索オプションを追加しました 。 この革新により、多くの可能性が開かれます。たとえば、特定のブランチの最後のパイプラインに対するリクエストを簡単に生成できるようになりました。 Dosukenはまた、前回のリリースに多大な貢献をしました-彼は、スケジュールされたコンベヤーの実行の基礎を築きました。 ありがとう

複数のタスク実行者（EES、EEP）

GitLabで作業する場合、一度に複数の人々の共同作業を必要とするタスクがしばしば発生します。 以前は、このような状況では、タスクが誰に割り当てられているかを理解することは困難でした。 これは、パフォーマーが毎日互いに連絡していない組織に特に当てはまりました。 GitLab 9.2のリリースにより、1つのタスクの実行者として必要な数のユーザーを指定できるようになりました。 それらはすべて同じレベルの責任を持ち、以前のバージョンと同じ通知を受け取ります。 すべてのアーティストはタスクリストとタスクボードに表示され、各アーティストはコントロールパネルでタスクとの接続を追跡できます。

注：これらの変更のため、 assignee_id タスクAPIパラメーターは古いため、 assignee_idsを使用assignee_ids必要がありassignee_ids 。 また、担当者JSONオブジェクトの代わりに担当者を使用する必要があります。

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

開発サイクル分析のローカリゼーション（サイクル分析）（CE、EES、EEP）

Hola Mundo、Halo Welt！ このリリースから、GitLabのローカライズ作業を開始しました。 この努力であなたのサポートを楽しみにしています！

バージョン9.2では、GitLabを世界中のあらゆる言語に翻訳するためのツールとインフラストラクチャが追加されています。 これまでのところ、テスト目的で、1ページ（Cycle Analytics）のみをスペイン語とドイツ語に翻訳しました。 将来のバージョンでは、新しいページを翻訳し、他の言語を追加します。 これを支援したい場合は、 手順を参照してください 。

GitLabの言語を変更するには、画面の右上隅にあるアイコンをクリックして、[設定]に移動します。

開発サイクル分析の詳細については、ドキュメントをご覧ください。

コンベア（CE、EES、EEP）の予定された打ち上げ

ほとんどのプロジェクトでは、新しいコミットごとにCI / CDパイプラインが起動されるため、コードに対するすべての変更は、アセンブリ、テスト、および展開を経て行われます。 ただし、特定のスケジュールでパイプラインを開始する必要がある状況があります。

GitLab 9.2のリリースにより、 必要なときに、必要に応じて頻繁にパイプラインの起動を構成できるようになりました。 パイプラインの毎日および毎週の起動、外部依存関係のチェック、または予防的な起動-これらすべてを簡単に構成できるようになりました。

この機能は、 スケジュールされたパイプライントリガーのインターフェイスのアルファバージョンを完全に置き換えます 。

コンベアの起動スケジュールの詳細については、ドキュメントをご覧ください。

Kubernetes（CE、EES、EEP）にGitLabをインストールします

GitLabをネイティブクラウド開発に最適なツールにしたいと考えています。 このため、 Kubernetesを簡単に使い始めることができることが重要です。 したがって、バージョン9.2で公式のGitLab Helmチャートがリリースされたことをお知らせします。

Helmは、Kubernetesクラスターでアプリケーションを展開、アップグレード、構成できるパッケージ管理ツールです。 GitLabとKubernetesは完全に連携します。CIのスケーリングやクラスターへの展開の自動化など、 Idea to Productionビデオで提示されたすべてのアイデアは、最小限の追加構成で簡単に実装できます。

ヘルムチャートを使用したGitLabのインストールの詳細については、ドキュメントをご覧ください。

マージリクエストのパフォーマンスへの影響（CE、EES、EEP）

ほとんどの場合、システムパフォーマンスに対する特定のマージの影響を追跡するのは簡単ではありません。 多くの場合、パフォーマンスデータには別のツールが責任を負っており、開発チームはそれにもアクセスできません。 開発者が行うすべての変更に対してこのデータを取得できるようにしたいと考えています。 プロメテウスとの統合は、この目標に向けた大きな一歩です。

GitLab 9.2以降、展開後のメモリ消費量の変更は、マージリクエストに直接表示されます。 開発者は、通常の作業プロセスから気を散らすことなく、生産性の変化を追跡できるようになりました。 将来のリリースでは、他のパフォーマンスメトリックを追加する予定です。

マージ要求がメモリ消費に及ぼす影響の追跡に関する詳細については、ドキュメントをご覧ください。

Disaster Recovery Alpha（EEP）の機能強化

バージョン9.0から、GitLab Geoにはアルファ版の災害復旧が含まれています。 新しいリリースごとに改善に努めており、GitLab 9.2も例外ではありません。 新しいバージョンでは、災害復旧がより便利になりました。コントロールの意味がより明確になり、複製プロセスに関するレポートがより詳細になりました。

リポジトリ複製メカニズムも改善されました。同期エラーにより破損したリポジトリの再同期が自動的に発生するようになりました。 さらに、プライマリデータベースを更新すると、自動的にセカンダリデータベースと同期します。

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

タスク名と説明の自動更新（CE、EES、EEP）

タスクページはコラボレーションの主要な場所であるため、そのコンテンツは常に変化しています。 GitLab 9.2以降、タスクの名前と説明はページを更新せずに自動的に更新されます。 したがって、タスクの最新バージョンを常に表示するには、タブを開いたままにしてください。 ブラウザのタブの名前も自動的に更新されます。

また、タスクの説明を編集すると、システムノートが追加されるため、コメントをスクロールするだけで、タスクの変更の完全な履歴を表示できます。 これらの変更はコメントの影響も受けました-編集時に同じ方法で自動的に更新されます。

ドキュメントのタスクの詳細。

検索バーのフィルターを削除する（CE、EES、EEP）

タスクの検索バーでフィルターを削除し、ワンクリックでリクエストをマージできるようになりました。

また、検索バーのショートカットのスタイルを変更しました。アプリケーション全体の残りのショートカットで色分けされています。

タスクおよびマージリクエストの検索の詳細

Elasticsearchによる検索の改善（EES、EEP）

Elasticsearchとの統合により、より高度な検索機能を追加します。 Elasticsearchを設定した場合、単語の一部を一致させることにより、正確なフレーズ（二重引用符）またはキーワードの順序なしのセットを検索するか、検索構文の他の機能を使用できます。 （これは、GitLabページの右上隅の検索バーに適用されますが、タスクおよびマージリクエストのリストの検索には適用されません。）

また、Elasticsearchのおかげで、インスタンス内のすべてのWikiでグローバル検索が可能になりました。

Elasticsearchによる高度な検索の詳細

GitLab 9.2のその他の改善点

タスク（CE、EES、EEP）からのマージ要求の作成

GitLabのすべてのイテレーションで、アイデアから生産への道をより速く簡単にしようとしています。

この新しい小さな機能を使用すると、タスクページから直接マージ要求を作成でき、GitLabはこれに必要なブランチを自動的に作成します。 これは、GitLabインターフェースから直接小さなコミットを行う必要がある場合に特に便利です。

タスクからマージ要求を作成する方法

個人スニペット（CE、EES、EEP）へのコメント

スニペット（個人的なものも含む）は、多くの場合一緒に機能します。 このアップデートでは、各スニペットとプロジェクトスニペットにコメントスレッドが表示されます。

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

レンダリングされたコードのプレビュー（CE、EES、EEP）

GitLabファイルを表示すると、SVGやMarkdownなどの多くのファイルがレンダリングされた形式でレンダリングされます。 ファイル表示ページで、ソースコードの表示モードとレンダリングされたファイルの間に便利な小さなスイッチが表示されました。

Google Compute Engine（CE、EES、EEP）でのGitLab RunnerのTerraformサポート

GitLab 9.1では、 HashicorpのTerraformを介してGCEにGitLabをインストールするためのサポートを開始しました。 バージョン9.2では、GitLab Runnerを展開する機能も追加し、アイデアから生産への原則でこれを補完します。

GitLabのTerraformリポジトリ

ユーザーインターフェイス（CE、EES、EEP）でジョブアーティファクトをプレビューする

アーティファクトには任意のファイルを使用できます。 このファイルにアクセスするには、ユーザーインターフェイスでアーカイブを直接検索します。 GitLab 9.2はこの検索の可能性を拡大しました。PDFファイル、画像、ビデオ、およびその他の形式は、タスクのアーティファクトの検索ですぐにプレビューできるようになり、ダウンロードする必要がなくなりました。

ドキュメント内のジョブアーティファクトの検索に関する詳細。

動的パス（CE、EES、EEP）のあいまいなルートの処理

GitLabには、特定の機能へのいくつかのパスがあります。 ネストされたグループの導入後、これらの機能は、名前がこれらのパスと競合するプロジェクトまたはグループからアクセスできなくなる可能性があります。 たとえば、「バッジ」と呼ばれるプロジェクトの場合、ビルドまたはカバレッジステータスのバッジは使用できなくなります。

このような誤解を避けるため、既存のGitLabルートと競合する可能性のある名前のプロジェクトまたはグループを作成する機能を削除しました。

そのようなパスのいずれかの名前のプロジェクトまたはグループがあった場合、それらはアップグレード中に自動的に名前が変更されます。 badgesと呼ばれるプロジェクトは、 badges0と呼ばれbadges0 。

git remote設定は、たとえば次のように手動で更新する必要があることに注意してください。

 git remote set-url origin git@gitlab.com:the-updated-path/the-updated-name.git 

dynamic_path_validator.rbで予約語の完全なリストを確認でき dynamic_path_validator.rb 。 このリリースで自動名前変更の影響を受けた既存のプロジェクトとグループのリストは、それらの名前を変更した移行で確認できます。

サブグループ作成の詳細

マージ要求を受け入れた後、ブランチはデフォルトで削除されます（CE、EES、EEP）

GitLab 9.2以降、マージリクエストのソースブランチはデフォルトで削除されます。 マージ後もブランチを保持したい場合は、マージ要求ウィジェットでオプションを無効にしてから受け入れてください。

CIジョブ（CE、EES、EEP）でファイルをキャッシュした後にアーティファクトを回復する

誰かが（偶然または意図的に） .gitlab-ci.ymlのキーワードcache （キャッシュ）とartifacts （アーティファクト）に同じパスを使用することがあり、古いキャッシュが誤って上書きされる可能性があります。パイプラインで使用されるアーティファクト。

このリリースから、アーティファクトはキャッシュ後に復元できるようになりました。緊急時にもアーティファクトが残り、利用できるようになります。

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

GitLab Mattermost 3.9

GitLab 9.2には、 Mattermost 3.9が含まれています。これは、Slackの代替となるオープンソースです。 このリリースでは、新しい統合カタログとポーランド語サポートを追加し、デスクトップアプリケーションにスペルチェックを追加し、さらに多くの便利な機能を追加しました。

バージョンにはセキュリティアップデートが含まれています 。 更新することをお勧めします。

GitLabレジストリ

GitLab Container Registryがバージョン2.4からバージョン2.6.1に更新されました。

マージリクエストの特定のレビュー担当者の指定（EES、EEP）

マージリクエストインターフェイスを使用すると、このリクエストを受け入れる（確認する）ことができる個々のレビュー担当者を選択できます。 プロジェクトの参加者のみに選択肢が提供され、プロジェクトが属するグループ（親グループ）、およびプロジェクトへのアクセスを許可されたグループ（プロジェクト共有）も選択できます。 したがって、適切なユーザーを簡単に見つけることができます。

マージリクエストレビューアーの構成の詳細

レガシーdiff（CE、EES、EEP）にコメントする

このリリースでは、マージ要求のディスカッションスレッドから古いdiffを直接参照できるようになりました。 これにより、開発、コラボレーション、およびレビュー中に古いコミットの内容にすばやくアクセスできます。 これらの古い差分にコメントを残すこともできます。

マージリクエストの詳細

展開はパフォーマンスボード（CE、EES、EEP）に表示されます。

製品のパフォーマンスが変化した場合、最初の質問は-作業環境は変化しましたか？ GitLab 9.2はこの質問にすばやく回答し、環境内のすべての展開をダッシュ​​ボードに表示します。 これにより、パフォーマンスの変化とアプリケーションの新しいバージョンとの関係をすぐに確認できます（GitLabを離れることなく、これらすべてを確認できます）。

環境モニタリング文書

手動アクションにより、安全なブランチが可能（CE、EES、EEP）

手動アクションには、リポジトリへの書き込みと同じアクセス権が必要になり、誰がそれらを実行できるかを制御できるようになります。 たとえば、安定したブランチから本番環境にコードをデプロイするタスクを、このブランチにコミットする権限を持つユーザーに対してのみ手動で起動する権限を残すことができます。

これは、プロジェクトの展開を保護するためにGitLabに追加するセキュリティ強化のリストの非常に重要な部分です。 詳細は、このタスクで読むことができます 。

すべての失敗（CE、EES、EEP）を要約した「失敗したジョブ」タブ

継続的インテグレーション（CI）を使用してプロジェクトに新しいコードをコミットすると、通常、パイプラインが正常に完了し、すべてが意図したとおりに機能したことを示すチェックマークが表示されます。 何か問題が発生した場合は、できるだけ早く詳細を調べる必要があります。 しかし、特にコンベアが複雑な場合、各段階とタスクの多数の移行はあまり刺激的ではありません。

GitLab 9.2では、パイプライン情報ページに[失敗したジョブ]タブが表示されました（[パイプライン]セクションで、特定のパイプラインを選択します）。 その上で、失敗したすべてのタスクのログを確認し、コンベアの全体像を評価できます。

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

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