Plan to Monitor (p2m) デモ

注: これが最新の動画です。これらのデモ手順を動画に合わせて更新する作業が進行中です。

概要

今日のモダンソフトウェア開発チームには、すべてのバージョン管理、自動テスト、複雑なビルドおよびデプロイメント設定のサポート、そしてソフトウェア開発と運用を時間をかけて改善するためのエンドツーエンドの可視性とトレーサビリティが必要です。しかし、ほとんどのチームにとって、このツール群を正しく構築するのは非常に困難です。

このデモは、計画から監視まで、Issue、計画、マージリクエスト、CI、CD、監視を通じて、GitLab の完全な DevOps ライフサイクルのための単一プラットフォームを強調します。

’’

GKE またはご自身の Kubernetes クラスタでこのデモを再現する際に問題が発生した場合は、Issue を開いてください。引き続きこのデモを改善する作業を進めています。idea-to-production の未解決 Issue 一覧も参照してください。

準備

  • デスクトップ通知を無効化します（Mac では右上隅を Option + クリック）。
  • 他のタブが見えないように新しいブラウザウィンドウを開きます。
  • 共有に適した妥当なサイズにブラウザウィンドウをリサイズします。1280x720 が良い選択肢です。https://handbook.gitlab.com/handbook/marketing/brand-and-product-marketing/product-and-solution-marketing/demo/720p.scpt は Mac で Chrome を使う場合に便利な AppleScript です。User Scripts フォルダーに追加し、メニューバーに Script メニューを表示すれば、簡単にトリガーできます。
  • 聴衆がメモや他のウィンドウに気を取られないように、ウェブブラウザのウィンドウだけを共有することも検討してください。
  • フルスクリーン表示する場合は、‘Displays’ 設定で Resolution: Scaled、Larger text を選択します。
  • 画面ロックを無効にした iPad でこのページを開くことも検討してください。

GitLab のインストール

4 つのオプションがあります:

  1. gitlab.i2p.online にログイン（GitLab セールス担当者向け）
  2. Google Kubernetes Engine (GKE) にクラスタをセットアップ
  3. Azure Container Service (ACS) にクラスタをセットアップ
  4. Minikube を使用したオフラインのローカルデモ環境

ライセンスを使用する必要がある場合、GitLab チームメンバーはライセンスをリクエストできます。

プロジェクトのセットアップ

クリーンアップ

  • 前回作成した GitLab グループを削除します
  • プロジェクト用の以前の Kubernetes 名前空間を削除します（kubectl delete namespace minimal-ruby-app-<project-id>）
  • 以前の Mattermost チームを削除するか、少なくとも Mattermost チームを離脱します

ユーザーを作成

注: 共有デモを使用する場合、各デモ実施者は一度だけこれを行う必要があります。

GitLab サーバーに新しいユーザーを登録します。

  • Register をクリック
  • 自分の名前とメールアドレスでユーザーを作成（検証は送信されません）

グループを作成（オプション、チャットを表示する場合）

GitLab を実行してログインしました。チームとして作業したいので、GitLab グループを作成します。グループを使うとプロジェクトをディレクトリに整理でき、複数のプロジェクトに一度にユーザーアクセスを付与できます。組織構造に合わせてグループの下にサブグループをネストすることもできます。ユニークな名前を付けましょう。

  • 左上のハンバーガーメニュー > Groups をクリック
  • New Group をクリック
  • グループにユニークな名前（デモを行う会社の名前、または架空の名前。すべて小文字、スペースや特殊文字は - 以外なし）を付ける
  • 公開レベルを Public に変更
  • Create group をクリック

プロジェクトを作成

注: 以前にデモを行ったことがある場合は、最初に minimal-ruby-app プロジェクトを必ず削除してください。

新しいプロジェクトを作成します。タイピングを節約するために、本当にシンプルなサンプルアプリからインポートします。

  • New Project をクリック
  • Import project の下で Repo by URL をクリック
  • Git repository URL を https://gitlab.com/auto-devops-examples/minimal-ruby-app.git に設定
  • Project name を minimal-ruby-app に設定
  • public にする

GitLab Auto DevOps をセットアップ

GitLab Auto DevOps を設定する準備ができました。これは GitLab CI/CD を、ベストプラクティスを多数組み込んだ状態で設定する最も簡単な方法です。CI/CD 設定に進みましょう。Auto DevOps を有効化してベースドメインを与えるだけです。

  • Settings > CI/CD に移動
  • Auto DevOps を展開
  • Default to Auto DevOps pipeline のボックスにチェック
  • KUBE_INGRESS_BASE_DOMAIN 変数を作成して、ドメインを i2p.online（または使用しているベースドメイン）に変更
  • デフォルトの Continuous deployment to production のままにする
  • Save changes をクリック

最初のパイプラインがキックオフされたのが分かります。これは後で詳しく見ますが、今のところ、何の労力もなく完全に機能する CI/CD パイプラインができたことを知っておけばよいです。

これでセットアップは完了です。

プロジェクトの権限（オプション）

これでアプリケーションを計画から監視まで進めるために必要なものはすべてセットアップされました。しかし、開発者に引き継ぐ前にソースコードを保護したいとしましょう。プロジェクトの権限を設定し、チームのワークフローを管理する重要な方法をいくつか紹介します。

ユーザーの役割と権限: これはパブリックプロジェクトなので、各チームメンバーが取れるアクションを管理する方法を確保したいと思います。たとえば、特定の人だけが master にマージしたり、CI プロジェクト構成を調整したりできるようにしたいかもしれません。

ユーザーの権限レベルを変更する: GitLab では、権限はユーザーレベルとグループレベルで管理され、プロジェクトと GitLab CI に適用されます。5 種類の役割タイプがあるため、きめ細かい権限を設定し、コードと構成管理を安全に保てます。管理者の時間と複数のログインの管理の手間を節約するため、GitLab は Active Directory と LDAP と統合します。GitLab を LDAP サーバーに接続するだけで、ユーザー、グループ、管理者を自動的に同期します。

プロジェクト設定: 権限に加えて、チームのワークフローを管理し、開発プロセスに品質管理を組み込む機能もあります。

保護されたブランチのプロジェクト設定に移動: コードレビューがコード品質を高く保つために不可欠なのは秘密ではありません。しかし、チームが期限に追われると、コードレビューをスキップして変更を強制プッシュするインセンティブが生まれることがあります。そのため、権限に加えて、保護されたブランチを識別して、レビューなしのコードプッシュを防ぐこともできます。master ブランチはデフォルトで保護されますが、QA ブランチなど他のブランチも簡単に保護でき、特定のユーザーまたはグループに push と merge のアクセスを制限できます。

マージリクエスト承認のプロジェクト設定に移動: コードレビューをさらに進め、コードが特定のチームメンバーによって常にレビューおよび承認されるようにしたい場合は、マージリクエスト承認を有効にできます。GitLab では必要な承認の数を設定し、プロジェクト内のすべてのマージリクエストの承認が必要となる承認者または承認グループの一覧を事前定義できます。

権限、マージリクエスト承認、保護されたブランチは、開発プロセスに品質管理を組み込むのに役立ち、開発者にアイデアを現実にする作業を始めてもらうために自信を持って GitLab を引き渡せます。

Plan to Monitor（旧 Idea to Production）（メインデモ）

Issue（計画）

最初の Issue を Issue ボードから作成します。

  • Issues > Boards に移動
  • Backlog 列の + をクリック
  • Title を Make homepage prettier に設定
  • Submit issue
  • 必要なら X をクリックして Issue を閉じる

ボード（計画）

インスピレーションは消えやすいので、これをすぐに取り上げましょう。これが初めてなので、ワークフローに合わせていくつかの列を追加する必要があります。これらの列は完全にカスタマイズ可能で、チームのリリース整理に役立つように 1 プロジェクトあたり複数の Issue ボードを持つことができます。デフォルトの “To Do” と “Doing” 列を追加します。

  • Add default lists

これで、新しい Issue をバックログから Doing 列に移動できます。今すぐこの Issue を解決したいからです。

  • Issue を Backlog から Doing にドラッグ

コミット（作成）

コーディングに進みましょう! Issue をクリックして、新しいマージリクエストを作成します。これは Issue 番号で始まる新しいブランチを作成し、関連付けを保ち、このマージリクエストがマージされるとこの Issue を閉じることを自動的に指定します。

  • Issue ボードカードの Issue タイトルをクリック
  • Create merge request をクリック

ブランチに進むと、本当にシンプルなアプリだとわかります。ファイルを表示すると、基本的にはハローワールドですが、監視をより興味深くするためにランダムなタイミングがあります。WebIDE を使ってメッセージを更新し、TODO コメントを削除します。

  • ブランチ名（例: 1-make-homepage-prettier）をクリック
  • server.rb をクリック
  • WebIDE ボタンをクリック

GitLab の一部である WebIDE は、クライアントに何の設定も必要なく開発環境を提供します。複数のファイルを編集し、変更をステージングし、プレビューし、コミットし、結果のパイプラインステータスを IDE からすべて表示できます。

  • Hello, world! を <h1>Hello, world!</h1> に変更
  • #TODO: use HTML 行を削除
  • Commit... ボタンをクリック

変更をコミットすると、WebIDE は即座に差分を表示するので、変更を素早く確認できます。コミットしたい変更をステージングし、コミットメッセージを追加し、ブランチに関するオプションを選べます。このブランチですでにマージリクエストを開始しているので、既存のブランチにコミットします。

  • server.rb をダブルクリックして Staged changes に移動
  • コミットメッセージとして Added HTML を入力
  • Commit to <あなたのブランチ名> branch が選択されていることを確認（例: Commit to 1-make-homepage-prettier branch）
  • Commit ボタンをクリック
  • ポップアップが通知の表示を求めたら、Allow をクリック

ビルドステージ（検証）

コミット後、WebIDE で自動的に貢献コードをテストする CI/CD パイプラインが起動したことが分かります。パイプラインには Build、Test、Review、動的テスト、Cleanup などの多くのステージが含まれていることが分かります。

  • WebIDE の右上の ロケットアイコン をクリック

ビルドジョブでは、Docker コンテナイメージをビルドし、組み込みコンテナレジストリにプッシュします。

  • Build ステージの View log ボタンをクリック
  • 表示されるペインをスライドして開き、より多くを一度に表示

Dockerfile がなかった場合、Heroku buildpack を使用して言語とフレームワークを検出し、適切な Docker イメージをビルドしていたでしょう。

ランナーの進捗

（オプション: CI/CD に時間がかかる場合）

実行中、Kubernetes コンソールに戻ると、GitLab Runner が Kubernetes と直接連携し、必要に応じて各ジョブのために新しいコンテナを生成しているのが分かります。プロジェクトの名前空間さえも作成し、隔離を提供します。

  • Kubernetes に移動
  • Namespace を default に変更
  • Pods をクリック
  • Namespace ドロップダウンを minimal-ruby-app-<番号> に変更
  • Pods をクリック

テストステージ（検証）

同じパイプラインを別の視点から見てみましょう。

  • < View jobs ボタンをクリックしてパイプラインビューに戻る
  • パネル上部の Pipeline ######（リンクのはず）をクリック

Test ステージでは 6 つのジョブが見えます…

コード品質（検証）

  • code_quality をクリック

code_quality ジョブはコードに対して静的解析を実行し、スタイリスティックなものやその他の品質問題を探します。これらの問題を早期に検出することで、修正コストを 100 倍以上安くでき、技術的負債を遠ざけるのに役立ちます。

コンテナスキャン（セキュリティ）

（オプション: GitLab Ultimate が必要）

  • 戻る（パイプラインビューへ）
  • container_scanning をクリック

container_scanning ジョブは、アプリケーション環境（コンテナ）を既知のセキュリティ脆弱性についてスキャンします。これにより、最初からアプリケーションができる限り安全な環境で実行されることが保証されます。

依存関係スキャン（セキュリティ）

（オプション: GitLab Ultimate が必要）

  • 戻る（パイプラインビューへ）
  • dependency_scanning をクリック

dependency_scanning ジョブは、アプリケーションが依存するライブラリのセキュリティ脆弱性を見つけて報告します。これにより、脆弱なライブラリへの依存をキャッチし、開発が進みすぎる前に修正する機会を提供します。

ライセンスコンプライアンス（検証）

（オプション: GitLab Ultimate が必要）

  • 戻る（パイプラインビューへ）
  • license_management をクリック

license_management ジョブは、アプリケーションの依存関係を分析し、使用したくないライセンスや決定が必要な新しいライセンスの存在を強調します。これにより、変更コストが高くなる前に、不要なライセンスを持つライブラリへの依存を早期にキャッチできます。

静的アプリケーションセキュリティテスト（セキュリティ）

（オプション: GitLab Ultimate が必要）

  • 戻る（パイプラインビューへ）
  • sast をクリック

sast ジョブはコードに対して静的アプリケーションセキュリティテストを実行し、既知のセキュリティ脆弱性を探します。セキュリティ脆弱性を早期にキャッチすることは、問題解決の作業の減少、コストの低減、最初からより安全なコードを意味します。

テスト（検証）

  • 戻る（パイプラインビューへ）
  • test をクリック

test ジョブは、再び Heroku buildpack を使って使用される言語を検出し、定義した言語に適したテストを実行します。この場合は Ruby なので、rake test を実行します。

レビュー（作成）

レビューアプリ

テストが合格すると、Kubernetes クラスタに一時的なレビューアプリが自動的に作成されます。

  • 戻る（パイプラインビューへ）
  • Review をクリック

ここで、Kubernetes へのデフォルトの Helm chart を使ったデプロイメントをハイライトに、自動で行っているたくさんのステップが見えます。プロジェクト自体に Helm chart があった場合、そのカスタム chart が代わりに使われていたでしょう。または、別の chart を指す project variable を追加することもできます。しかしここでは、デフォルトを使っています。

レビューアプリの素晴らしさを見るために、マージリクエストに戻りましょう。

  • パイプラインの上の commit ID をクリックして、コミットページへ
  • コミットページから、リンクされた MR（"!" で始まる）に移動

レビューアプリにデプロイされたことを示す新しい行と、変更が実際に動作している URL がここに表示されます。これは素晴らしいです。コードを読むだけでは信用したくない、本番のような環境で実際に動いているのを見たい、そしてこのレビューアプリがそれを提供します。

  • レビューアプリへの外部リンクをクリック

これが先ほど変更した内容で、ブランチにプッシュされた新しい変更はアプリを自動的に更新します。

マージリクエストに戻りましょう…

  • レビューアプリのタブを閉じる
  • Code quality で Expand をクリック

コード品質のための新しい行があり、TODO の削除を気に入っていることが分かります。状況を悪化させた場合も、ここに表示されます。

そしてセキュリティスキャンの新しい行があり、セキュリティ脆弱性が検出されなかったことを示しています。

コードレビュー

この時点で通常はチームの別の開発者にマージリクエストをレビューするよう依頼します。彼らは変更された正確なコードを見て、コメントでき、ディスカッションのスレッドが見え、もちろんメール通知も届きます。

  • レビューアプリのタブを閉じる
  • environment タブを閉じる
  • Changes をクリック
  • 変更された行をクリックしてコメント機能を表示
  • “Looks good” とコメント、Comment
  • Discussion タブに移動してコメントを確認

master へのマージ

すべて素晴らしく見えるので、WIP ステータスを削除して変更を master ブランチにマージしましょう。

  • Resolve WIP status をクリック
  • Remove source branch にチェック
  • Merge をクリック

本番環境（パッケージ & リリース）

  • CI/CD > Pipelines をクリック
  • 一番上のパイプラインをクリック

新しいパイプラインがキックされたのが分かります。このパイプライン内では、見覚えがあるけれど少し違って見えます。レビューアプリを作成する代わりに、これは本番環境に直接デプロイしています。これは継続的デプロイメントの最高の形です。

デプロイ履歴付き環境

  • Environments に移動

Environments ページに移動すると、production が表示され、最後のデプロイは 1 分未満前に発生したことが分かります。簡単にクリックして、どう見えるか確認できます。

  • 外部 URL リンクをクリック（一番左のボタン）

できました! 計画から監視まで、新しいフォーマット変更を取得しました!

  • 本番アプリのタブを閉じる

スケーリングとデプロイボード（設定）（オプション: GitLab EE が必要）

このページにはまだあります。production のデプロイボードが見えます。今はポッドが 1 つしか表示されていませんが、スケールアップしましょう。CI/CD 設定に移動して、PRODUCTION_REPLICAS を 4 に設定するプロジェクト変数を追加します。

  • Settings -> CI/CD
  • Secret variables を展開
  • キーを PRODUCTION_REPLICAS に設定
  • 値を 4 に設定
  • Add new variable

戻ります。再デプロイできます。

  • 環境リストに戻るために 2 回クリックするか、CI/CD > Environments に移動
  • Re-deploy をクリック

すぐに、デプロイボードがフリートのロールアウトとともにリアルタイムで更新されるのが見え、デプロイが終了するのを少し待つことができます。

監視

ですから、デプロイの高レベルなステータスはこれですが、アプリ環境の継続的な健全性を監視するのはどうでしょうか? グラフアイコンをクリックすると、レイテンシ、エラー率、スループットを含むレスポンス指標、CPU とメモリ使用量を含むシステム指標が見えます。これらはすべて組み込みの Prometheus 監視（先進的なオープンソース監視ソリューション）から取得されます。今は見るものがあまりありませんが、これは過去 8 時間を表示するので、アプリの状態を監視できます。各デプロイの線もあるので、最近のデプロイによる性能変化を相関付けられます。アプリケーションパフォーマンス監視は、チームが単にエラーに反応するのではなく、エラーを防ぐより戦略的になるのに役立ちます。アプリケーション監視ツールが、最初からパフォーマンスの低いコードのプッシュを避けるのに役立ち、ビジネスの将来の下流コストを節約できたら想像してみてください。それが私たちが目指している方向です。

ループを閉じる（オプション）

ここでループを閉じて、マージリクエストに戻りましょう。すでにマージされているので、適切なタブで探す必要があります。

  • Merge Requests > Merged に移動
  • 一番上のマージリクエストをクリック

マージリクエストでは、このコードが実際に本番環境にデプロイされたことを示す別のステータスが見えます。これはマネージャーがクローズされたマージリクエストを見て、実際にデプロイされたかどうかを知るのに最適です。しかし、私たちはさらに進んで、マージリクエストに直接、アプリケーションのパフォーマンスについてのフィードバックを表示します。マージリクエストがデプロイされる前と後でメモリ使用量がどれだけ変化したかを伝えます。

カスタムパイプライン - ステージングとカナリア（オプション: GitLab EE が必要）

これでビルド、テスト、コード品質、レビューアプリ、本番デプロイ、監視からの Auto DevOps をカバーしました。かなり素晴らしいです。しかし、何か違うことをしたい場合はどうでしょうか?

ここで CI を手動で設定します。しかし、ゼロから始めて、私たちが見たすべてを再作成するのではなく、テンプレートから Auto DevOps を選択し、すべてをインポートできます。

  • Overview に移動
  • Set up CI をクリック
  • Auto DevOps テンプレートを選択

ここには多くがありますが、最初に見えるほど怖くはありません。すでにここに役立つヒントがいくつかあります。本番環境への継続的デプロイメントの準備ができていない場合は、このステージングジョブのコメントを外すだけです。カナリアデプロイメントを追加したい場合は、これのコメントを外します。次にこの最後の 1 行のコメントを外して、本番デプロイを手動にすれば、準備完了です。

  • ステージングジョブの先頭の . を削除
  • カナリアジョブの先頭の . を削除
  • 本番ジョブの when: manual 行の前の # を削除

これを master に保存します。新しいパイプラインがキックされたのが分かります。これも見覚えがありますが、ステージングとカナリアの 2 つの新しいステージがあります。

  • Commit changes を master に
  • CI/CD > Pipelines に移動
  • 一番上のパイプラインをクリック

ステージングのデプロイ完了を待ちましょう。これで環境に戻り、新しいステージング環境があるのが見えます。この設定では、ステージングは最新の変更で自動的に更新されます。

  • CI/CD > Environments に移動
  • staging 外部 URL をクリック
  • staging タブを閉じる

しかし、本番環境はもう自動的に更新されません。準備ができたら、ステージングから本番環境に手動でプロモートする必要があります。しかし、私たちは本番フリート全体に直接出荷するつもりはありません。GitLab はカナリアデプロイをサポートしており、基本的にはフリートの一部にデプロイしてリスクを減らします。ここで Canary 手動アクションをクリックしてデプロイメントを開始します。デプロイボードで、カナリアデプロイメントが進行中なのも見えます!

  • staging の手動アクションのドロップダウンをクリックし、Canary を選択
  • staging のデプロイボードを展開

これで、新しいカナリアコードを実行する 1 つの新しいポッドが本番環境にあり、本番トラフィックの一部を引き受けていますが、残りのポッドは古いコードを実行しています。これはデプロイメントのリスクを減らす素晴らしい方法です。

カナリアが期待どおり動作していることを検証したら、それを完全に本番環境に出荷できます。今やってみましょう。

  • production 手動アクションをクリックし、Production を選択
  • デプロイメントが終わるのを待つ
  • production 外部 URL をクリック

素晴らしい、本番環境に入りました!

ですので、本番環境への継続的デプロイメントが必要でも、もっとコントロール下にある継続的デリバリーフローが必要でも、まったく別の何かが必要でも、私たちは対応できます。

  • production タブを閉じる

フィードバック（Cycle Analytics）（オプション）

開発プロセスのボトルネックを発見するのに役立つよう、GitLab には計画から監視まで進むのにチームがどれくらい時間がかかるかを追跡する組み込みダッシュボードがあります。

  • Overview > Cycle Analytics に移動

ここでは、プロジェクトの全体的な健全性に関するいくつかの指標が見え、計画から監視までの各ステージで費やした平均時間の内訳が見えます。これまでのところ、私たちは数分でリリースサイクルを完了しており、驚くほど良い結果を出しています。

これは、競争力を維持し、顧客や変化する市場ニーズに応えるために重要な、会社のリリースサイクルタイムをよりよく理解しようとするマネージャーにとって素晴らしいです。

インスタンス監視（オプション）

Prometheus はアプリだけでなく GitLab インスタンス自体も監視します。Prometheus ダッシュボードに移動しましょう。

  • Prometheus を訪問 https://prometheus.i2p.online（GitLab インストールに使用したドメインに合わせてドメインを変更）

GitLab インスタンスの動作を示すいくつかの簡単なクエリを見てみましょう。これが CPU 使用率です:

  • 1 - rate(node_cpu{mode="idle"}[5m]) を Expression バーにコピー、Enter キーを押す。
  • Graph をクリック

そしてメモリ使用率:

  • (1 - ((node_memory_MemFree + node_memory_Cached) / node_memory_MemTotal)) * 100 を Expression バーにコピー、Enter キーを押す。

結論

これがすべてです。10 分未満で、Issue 追跡、Issue ボードによる計画、リポジトリへのコミット、継続的インテグレーションによるテスト、マージリクエストとレビューアプリによるレビュー、ターミナルでのデバッグ、本番デプロイ、アプリケーションのスケーリング、アプリケーションパフォーマンス監視、Cycle Analytics によるフィードバックループのクローズなど、完全な DevOps ライフサイクルを通してアイデアを取り組みました。そしてこれらすべてが、GitLab、CI のための GitLab Runner、デプロイするアプリケーションのスケールを可能にするコンテナスケジューラの上にあります。GitLab、DevOps ライフサイクル全体のための単一アプリケーションへようこそ。モダンアプリケーションを計画から監視まで素早く確実に届けるお手伝いをします。

最終更新 May 6, 2026: Merge pull request #100 from kyama0/fix/upload-images-tolerate-upstream-missing (70970e1a)
ページのソースコードを見る - ページの編集 - please contribute. Creative Commons License