統合開発ツールチェイン環境GitLab CE 10.6が2018年3月22日にリリースされました 
実は2018年2月くらいにGitLab CEはGitLab Libreという名称になっていました。が、また近々名前が変わります。GitLab CE 10.7リリースノートを楽しみにしていてください。
日本人唯一のGitLab Core Teamの @tnir です。GitLab.JP/GitLab Tokyoオーガナイザとして日本語圏でのマーケティングも注力しています。
GitLabには、大きく分けてCommunity Edition (CE) とEnterprise Edition (EE) とありますが、本記事はCEにフォーカスしています。
2018年2・3月のGitLabトピック(一部)
3/3〜3/5にかけてGitLab Issue Bash 1Q 2018がオンライン上で開催されました。参加された方には抽選で15名にGitLabグッズが届きますので、楽しみにしていてください。
3/10には大阪でGitLabの開発に関するイベントが開催されました。同時間帯で開催された東京のOSS Gateでも取り組みがあったようです。
私自身もGitLab CE 10.6においてCEに4件のMRを入れてみました。
そのうちの1件（branches overview）の取り組みにより、MVPに選ばれました
GitLabはまだまだUI/UX/機能/パフォーマンスが不十分なため、ご興味のある方はぜひコントリビューションにご参加ください。
外部Gitレポジトリ向けGitLab CI/CD (GitLab CI/CD for external repos)
2011年時点ではGitLabはコードレポジトリ(SCM)として始まったものの、その後、テスト、セキュリティ、パッケージング、デプロイ、モニタリングを含むcomplete DevOpsライフサイクルを支えるツールとして成長してきました。このリリースはGitLab CI/CD/モニタリングをGitLab以外でホストされているアプリケーションコードでも利用できるようになりました。
GitHubレポジトリに対してGitLab CI/CDを使うには、GitLab上で新しいプロジェクトを作成します。 CI/CD for external repo タブから GitHub をクリックして、GitHubにログインし、既存Githubレポジトリを選択します。 .gitlab-ci.yml ファイルをレポジトリに追加するか、Auto DevOpsを有効化すると、GitLabは自動的にCIパイプラインを開始して、その結果をGitHub上のコミットステータスを更新します。
その他のGitレポジトリもURLでステータスwebhookを設定してやることで連携できます。例えば、Bitbucketを使っていれば、手動でGitLab CI/CDを有効化する を見てください。
新機能リリース記念で、GitLab.com上で2019年3月まで無料で利用できます。
関連ドキュメント
KubernetesクラスタへのGitLab Runnerの高速デプロイ (Quick deploy of GitLab Runner to Kubernetes cluster)
GitLabはこれまでもHelm、Ingress、PrometheusをKubernetesクラスタに簡単にデプロイできるようにしてきました。
GitLab 10.6では、1クリックで自分のKubernetesクラスタにプロジェクトからGitLab Runnerをデプロイできるようになりました。
追加設定なしでそのプロジェクトのジョブを実行することができます。
関連ドキュメント
Kubernetesクラスタ上のIngress IPアドレス (Ingress IP address on Kubernetes cluster page)
GitLab 10.2で、自分のKubernetesクラスタにIngress
ができるようになりました。Ingressをインストールすることで、デプロイされたアプリケーションへの
外部からアクセスできるパブリックIPアドレスが使えるようになります。
GitLab 10.6では、GitLab上のKubernetes設定ページのUIから、その直接IngressコントローラのIPアドレスを確認できるようになりました。
これをドメインネームと紐付けて設定してやることで、インターネット上からデプロイされたアプリケーションへアクセスできるようになります。
関連ドキュメント
ForkプロジェクトからのMRへ元プロジェクトへの管理者によるプッシュ (Maintainers can push to MR from fork)
ForkのワークフローはGitLabを初めとするオープンソースプロジェクトで広く利用されています。
コントリビュータは元のプロジェクトからforkし、コミットした後、元プロジェクトへMRを作成します。
ForkプロジェクトからのMRをレビューする際、元プロジェクトのメンテナはマージする前に小さな修正をしたり、
デフォルトブランチに対してrebaseしたりすることができるようになりました。
これにより、コミュニティからのコントリビュータとメンテナの間での無駄なやり取りが減ることでしょう。
もちろん、メンテナは小さい修正だけでなく、大きな修正においてもコントリビュータを助けることができます。
これまでのバージョンでは、元プロジェクトのメンテナにはfork先プロジェクトへの書き込み権限がないため、
直接fork先のプロジェクトにコミットをプッシュすることはできませんでした。
今回のリリースでは、MR作成者がMRの元ブランチに書き込み権限がある場合に、
MR作成者が元プロジェクトのメンテナにコミットプッシュ権限を付与できるようになります。
MRを作成する際または編集する際、 Allow edits from maintainers を有効にすることで
権限付与ができます。
有効化された場合、MRのマージ先ブランチへマージする権限があるユーザ（master）はMRの元ブランチに
書き込めるようになります。
デフォルトでは、このオプションは有効化されていません。
関連ドキュメント
1 Group Issue BoardがCE/Freeに登場 (Single Group Issue Board in Libre and Free)
GitLabのGroup Issue Boardでは、1個のグループの複数プロジェクトを横断した形でイシューの管理ができます。
プロジェクトのIssue Boardと同じようにグループのIssue Boardが使え、プロジェクトをまたいでワークフローステージの移動ができるようになっています。
これまで、この機能はEE (EEP/EEU)のみで利用可能でした。
EEPユーザからの評価が高かったことに加え、GitLab Libre (CE) ユーザからもこの機能を要望され、
1 Group Issue Boardでもあると便利だという意見がありました。
このリリースで、Libre (CE) および EE Starterのユーザでも利用できるようになり、1グループで1個のGroup Issue Boardが使えるようになりました。
1グループで複数個のGroup Issue Boardが使えるのは、これまで通り、EEP/EEUのみの機能です。
対応する形で、GitLab.comの無料、ブロンズユーザも1グループで1個のGroup Issue Boardが使えるようになりました。
1グループで複数個のGroup Issue Boardが使えるのは、これまで通りGitLab.comのSilver/Goldユーザのみです。
うまくフィードバックすれば、Libre (CE)、GitLab.com Freeユーザでも今後複数Issue Boardが使える可能性がありますので、使ってみてフィードバックしていくといいでしょう。
関連ドキュメント
Branchダッシュボード (Branches overview)
プロジェクトやチームが成長するにつれて、branchesの数も増えていきます。
今回導入されたBranchダッシュボード、フィルターリストでは、新旧のbranchを区別して表示できるので、より探しやすくになるでしょう。
Active/Stale branchの分類は直近3ヶ月以内にコミットのあるbranchかどうかになります。3ヶ月以内だとActive、3ヶ月以上だとStaleです。
一度コミュニティからMRが提案されていましたが、放置されていたので、私 @tnirが仕様を再設計して、ゼロから作り直しました。
（完璧から程遠いので、どんどん改善していきたいですね）
関連ドキュメント
外部イシュートラッカーへのリンク (Navigate to external issue tracker)
GitLabを利用中の組織には、外部イシュートラッカーと連携している会社も少なくありません。
例えば、JIRAイシューとGitLab MRを組み合わせて使うのはたくさんのチームでよく見かけるワークフロー例です。
この例でも、GitLabイシューは正しく機能しますし、チームメンバーはそれを使うことができますので、一時的にGitLabで全部完結させることもできます。
この連携を簡単にするために、プロジェクトの左のサイドナビゲーションに外部イシュートラッカーへのリンクを追加しました。
Redmine、JIRA、Bugzilla、その他のイシュートラッカーをGitLabプロジェクトの外部トラッカーとして設定している場合は、
プロジェクトの左のサイドナビゲーションに外部トラッカーへのリンクが追加されるので、外部イシュートラッカーへのアクセスが簡単になります。
この場合も、GitLab本体のイシュートラッカーへのアクセスは可能です。
関連ドキュメント
プロジェクトのインポート/エクスポートAPI (Project import/export API)
GitLabにおいてプロジェクトは、Gitレポジトリを含む価値のある成果物全てやイシューやMerge Request (MR)などの集まりを含んでいるので、とても重要です。
GitLabの既存プロジェクトのエクスポート/インポート機能を使うと、プロジェクトをインスタンス内またはインスタンス間でプロジェクトを簡単に移行することができます。
これまでのエクスポート/インポート作業は手動作業のみでした。本リリースでは、エクスポート/インポートがGitLab APIとして導入されたので、
自動化やカスタムのワークフローの実現が可能となりました。
こちらもなんとTravis Miller氏によるコミュニティコントリビューションです。
MVPではなかったけれど、MVPに相当する価値のあるAPIですね。
関連ドキュメント
Discussion API (Discussions API)
イシュー、スニペット(GitHubのGistに相当)、エピック(EEPのみで提供)のDiscussion（ノートをまとめたもの）をAPIとしてリリースされました。
これにより、イシューのコメントやdiscussionがAPIを通じて利用できるようになりました。
より柔軟なワークフローや便利なクライアントが出てくることが期待されますね。
MRへのコメントやdiscussionのAPIサポートは今後のリリースで提供開始されるとのことです。
私個人としては、週末ちょうどMRへのコメントのWeb UIの再実装に取り組んでいたところだったので、ありがたいAPI機能だと感じました。
関連ドキュメント
フィリピン語、インドネシア語、トルコ語の言語サポート追加 (Filipino, Indonesian, and Turkish language support)
GitLab国際化対応の取り組みの中で、新たにフィリピン語、インドネシア語、トルコ語の言語サポートが追加されました。
国際化の別の取り組みとしてWeb UIの国際化が進められたようですが、EE(EEP/EEU)のみで提供されるレポジトリでのロックファイル機能のみのようなので、ここでは省略します。
上記言語に先んじて、日本語のサポートは提供されています。日本語でもコントリビューションを募集していますので、translation communityを参考に翻訳に参加してみてはいかがでしょうか。
関連ドキュメント
GitLab Runner 10.6
GitLab本体と連携しGitLab CI/CDの実行環境を提供するソフトウェアGitLab Runnerも10.6がリリースされました。
主な変更点:
CI_RUNNER_VERSION,CI_RUNNER_REVISION,CI_RUNNER_EXECUTABLE_ARCHという名前のジョブ環境変数の追加- Docker Executorでの実行時に必ず新しいコンテナが作成されるように
- S3キャッシュでインスタンスに割り当てられたIAMロールが利用されるように
- 一度deprecatedされたgitlab-runner execがdeprecatedでなくなりました
- キャッシュキーが空の場合にキャッシュ操作を省略したことを表示するように
- ベースをGo 1.8.5から1.9.4へアップデート
その他の変更点については、GitLab RunnerのCHANGELOGを見てください。
関連ドキュメント
omnibusパッケージの改善 (Omnibus improvements)
オールインワンパッケージのomnibusでも以下の修正がされています。
- GitLab Mattermostが4.7にアップデートされました。
- 画像プレビューやURLサムネイルの改善、レスポンスタイムの高速化、デスクトップアプリの更新、セキュリティアップデートが含まれています。アップデートを推奨します。
- Chefが13.6.4にアップデートされました。
- Omnibusが5.6.10にアップデートされました。
- PostgreSQLが9.6.8にアップデートされました。
- Pythonが3.4.8にアップデートされました。
- jemallocが5.0.1にアップデートされました。
- Redis/Sentinelで
announce-ipとannounce-portが設定できるようになり、Docker環境でHA構成が容易になりました。ato better support HA in Docker environments.
関連ドキュメント
パフォーマンス改善 (Performance improvements)
ここ数年かなり改善されたとは言え、2018年のGitLabにとってパフォーマンスの問題は重要です。GitLab 10.6でも非常に多くのパフォーマンス改善がなされていますが、
その中で、重要なパフォーマンス改善は以下の通りです:
- プロジェクト/グループ検索の結果を1000件までに制限し、データベースタイムアウトを抑止
- Merge request詳細表示時のGitaly大量呼び出し(N+1問題)抑止
- Merge request変更差分表示時のGitaly大量呼び出し(N+1問題)抑止
- MRがマージ可能かどうかというステータスをキャッシュ化し、MRウィジェットポーリングを高速化
- ユーザアクティビティリストのレスポンスタイムの改善
関連ドキュメント
Deprecation: The gitlab Helm chart
先月からお伝えしていた通り、2018年3月22日にgitlab Helm chartが廃止されました。2018年4月現在、Kubernetesへのデプロイはgitlab-omnibus Helm chartを使う必要があります。
さらに新しいcloud native GitLab chartは現在開発中です。2018年中にはgitlab-omnibus Helm chartはこちらのcloud native GitLab chartにリプレースされる見込みです。
本ドキュメントのライセンス
- カバーイメージ: Unsplash free license
-
その他:
CC BY-SA 4.0
お知らせ
直前で申し訳ないですが、4/10夜に東京でGitLab Meetup Tokyo #7が開催されますので、ご興味のある方はご参加ください。日本初のGitLab本を書いた人も登壇します。（GitLab Tokyo/GitLab.JP調べ）