Sentryでエラートラッキング
アプリケーションが生成するエラーに注意しておくことで、ユーザが問題点に気づいて報告して来る前にそれに気づけ、良いユーザ体験を提供し続けられます。また、もし問題が起こったらより早期に解決できます。
GitLab11.8では、有名なオープンソースのエラートラッキングツールである、Sentryを組み込むことでより便利かつ効果的にエラーをモニターできるようになります。また、GitLabプロジェクトの最新のエラーを表示してくれます。
Sentryは最近、不審なコミットやリリースを検知したり、コミットを追跡するなど、GitLabとの連携を深めています。 GitLab/Sentry両者の組み合わせにより、GitLabからSentryへの連携が簡単になり、SentryからGitLabも連携しやすくなります。そのため、既存のワークフローを崩すことなく、いつもエラーの状況を確認することができるのです。
テンプレート利用により、ワンクリックでPagesを利用可能に
今回、最もポピュラーなPagesのテンプレートをGitLabに搭載しました。以前のようにサンプルテンプレートをforkすることなく、新規にプロジェクトを立ち上げた画面からPagesのサイトを作ることができます。 より詳細な情報はPagesのテンプレートについてのブログをご覧ください。
サブグループでPagesが利用可能に
PagesがGitLabのサブグループでも使えるようにアップデートされ、サブグループでのPages作成ができるようになりました。 この方法で設定されたサイトはtoplevel-group.gitlab.io/subgroup/projectの形式のURLを付与されます。 プロジェクトで(サブグループ一部でも)ソフトウェアリリースの一環としてドキュメントや他のサイトを作成することができるようになります。
マージリクエストに関する承認ルール
コードレビューは全ての成功したプロジェクトでの基本的なやり方ですが、誰が変更をレビューすべきかは必ずしも明確ではありません。 エンジニアリング, UX, 製品など様々なチームからのレビュー担当者がいることが望ましいことがよくあります。
GitLab 11.8 での新しい承認ルールでは、承認者とそれぞれの最小承認数を設定することで、コードレビューに参加すべきユーザーをより適切に伝えることができます。 承認ルールはマージリクエストのウィジェットに表示されるので、次のレビュー担当者をすばやくアサインすることができます。
GitLab 11.3 では、プロジェクトのどのコードに対してどのチームメンバーが責任を持つのかを示すために Code Owners を導入しました。 コードの所有者は承認ルールに統合されているため、変更をレビューするのに適した人を常に簡単に見つけることができます。
承認ルールは 11.8 ではデフォルトで無効になっているため、管理者が Rails コンソールで Feature.enable(:approval_rules) を実行して有効にする必要があります。
GitLab.com では承認ルールが一時的に無効になっています。 GitLab 11.8.1 を適用した後で再び有効になる予定です。 本アップデートについては この課題 を参照してください。
プロジェクト間パイプライントリガーの機能改善
複数プロジェクトパイプライン は GitLab 9.3 から提供されており、ジョブ内で GitLab API を介してダウンストリームパイプラインをトリガすることで作成できます。 11.8 では更に「trigger:」キーワードを使用して、これらのダウンストリームパイプラインをトリガするためのファーストクラスサポートが追加されました。このキーワードは現在のパイプラインが成功したときにダウンストリームパイプラインを自動的にトリガするブリッジジョブに追加できます。
Squash コミットメッセージを改良
後々の人のために信頼でき、有用なGitの履歴を残しておくことは、フィードバックをクローズしたり、単体テストを修正するために軽微なコミットをすることと相容れないことがあるかもしれません。 コミットを Squash すると今までのコミットを1つにまとめることができますが、同時に、あなたが考え抜いたコミットメッセージを消してしまいます。 GitLabでは、 Squash コミットのメッセージをデフォルトでフィーチャーブランチの最初の複数行メッセージに設定し、コミットメッセージを上書きして更新し、重要な変更を反映できるようにしました。
AutoDevOpsが環境固有のカスタムドメインをサポート
プロジェクトに”ベースドメイン”を付与して簡単にAuto DevOpsを使い始めることができます。 アプリケーションを製品としてデプロイする準備ができたら、独自ドメインやFQDNを使いたくなるかもしれません。 今後はアプリケーションで使う1つ、それ以上の独自ドメインを設定するために ADDITIONAL_HOSTS という環境変数を使えるようになります。 さらに、環境名を変数の前に付けることで、特定の環境について表現することができます。 例： <ENVIRONMENT>_ADDITIONAL_HOSTS
Aaron Walker さんの貢献に感謝します！
Knative ファンクションを実行中の Pod の数を表示
GitLab Serverlessを使用してファンクションをデプロイすると Knative の良さをすべて享受できます。サーバーレスのデプロイをスケールアップしたりゼロにスケールダウンすることが可能です。
このリリースから、 Knative インスタンスにデプロイされた各アプリケーションまたはファンクションに対するサーバーレスデプロイメントが、どれくらいスケールされているかを確認できます。 スケールは現在使用中の Kubernetes Pod の数で表示されます。
