はじめに
どうも！生産技術部のエンジニアです。今回は、コマンド操作？Git?という職場でも前を向いて進めるように、と開発環境、Gitを用いたブランチモデルを検討しています。それなりに固まってきましたので紹介します。
GitLabサーバを一から構築される方は、以下からご覧ください。
「proxy環境下でDocker Composeを用いてCentOS7上にGitLab Dockerを作成」
前提条件
これらの条件の下で、ストレスなく開発できる環境を目指す。
- 全員がWindowsユーザ
- 全員がコマンド操作をしたことがなく、GUI操作のみ
- 全員がGitを使ったことがない
- コンパイラ、開発環境、本番環境が独自のシステム
- 会社的にクラウド環境の利用が困難であり、オンプレミス環境のみで完結したい
検討中の開発環境
検討中の環境を以下に示す。ビルド、単体テスト、運用フェーズは独自のシステムを利用している。それ以外のフェーズで検討した結果を紹介する。ビルド、単体テストについては環境構築中であり、安定したシステムになり次第、紹介する。
開発ツール
まず初めに考えなければいけない事は、コマンド操作をできる限り使わずにGit操作が出来なければいけない。Git操作をGUIで行えるTortiseGitが一般的に広く用いられている。WindowsユーザにとってToutiseGitは、エクスプローラ上で操作ができ、視覚的にファイルの管理状態が見えるため強力なツールだと感じている。しかし、Gitを使ったことが無いユーザにとっては、Gitの概念（ローカルリポジトリ・リモートリポジトリ・ブランチ等）が見えにくく、誤った操作を招く可能性がある。そこで、VSCode標準のGit管理ツールを利用することにした。VSCodeのGit管理ツールは、コマンドがボタンに置き換わっている程度のシンプルなものであり、Gitの概念を理解し操作が行える。また、Git HistoryやGitLensなどの拡張機能があるのも魅力的である。
Gitリポジトリ管理ツール
Gitリポジトリの管理には、GitLabを採用した。理由は、
- 利用するユーザ数、リポジトリ数に制限が無い、
- GitLab Runnerとの連携によりCI/CDが既にサポートされている事、
- チャットツール(Mattermost)が利用できる、
- 強力なリバースプロキシ(NGINX)を利用できる、
- 強力なログ可視化ツール(Grafana/Prometheus)が利用できる、
など様々であるが、これらのアプリケーションが既に同封されており、GitLabのインストールのみで既に利用可能で有ることが最大のメリットである。gitlab.rbの設定を書き換えるだけで簡単にカスタマイズが可能である。また、GitLabの導入が難しいと思われがちだが、実際にやってみると驚くほど簡単にセットアップが出来る。サーバの故障対応や、別のサーバに移行がしやすい等の運用のし易さを考慮し、Docker/Docker composeを用いて構築した。これは、現状のサーバの管理者が自分だけであり、他の管理者に任せられる仕組みにしたいと言う想いからである。
検討中のブランチモデル
続いて現在検討中のGitを使ったブランチモデルについて紹介する。我々のソフトウェアは製品を検査するためのものであり、結合テストでは、デバッグ用の設備にソフトウェアをデプロイし、実際に設備上で検査をかけテストを実施する。この事を考慮した検討中のブランチモデルはメインブランチ(master/develop)とサポートブランチ(feature/hotfix)で構成される。各ブランチは以下の用途で用いられる。
※Hot-fixとDevelopで同一ファイルを編集した際にコンフリクトが発生する点については、現在検討中です。
- master
- 常にデプロイ可能であり、本番環境へのリリースに用いる。
- develop
- 単体テストが完了しており、デバッグ用の設備へのデプロイに用いる。
- feature
- 新しい機能を追加するために用いられる。
- hotfix
- 製品に致命的なバグがある場合の緊急で修正する場合のブランチである。
これは、Git flow、GitHub flow、GitLab flowを参考にした。各ブランチモデルの概略を以下に説明する。
Git flow
多くのプロジェクトで利用されるフローであり、コマンドラインの補助ツールなども提供されている。Git Flowはメインブランチ(master/develop)とサポートブランチ(feature/release/hotfix)で構成され、メインブランチは以下の状態を持ち、サポートブランチは以下の役割を持つ。
- master
- リリース可能な状態である。
- develop
- 次のリリースのための"Work in progress"の状態であり、常に最新の変更を含んでいる。
- feature
- 新しい機能を追加するために用いられる。
- release
- 新しい製品をリリースするための準備に用いられる。
- hotfix
- 製品に致命的なバグがある場合の緊急で修正する場合のブランチである。releaseブランチと似ているが、計画外のリリースに用いられる。
それぞれのブランチの役割が明確であり、ブランチ毎の機能が細分化されているため、大規模な人数でのプロジェクトにも適応できる。
GitHub flow
Git Flowは、複雑であることや、GUIツールではなくコマンドラインでしか使えないと言った問題が挙げられる。これらの問題を解決するために提案されるのがGit Flowである。GitHub Flowの特徴を以下に挙げる。
- シンプルであること。masterと機能追加用のブランチのみである。
- プロダクション環境へのデプロイを毎日（たいていは日に何回も）行うため、「リリース」というものがない。
- 「hotfix」ブランチはない。小さな機能追加であり、通常のプロセスの一貫でしかない。
このブランチモデルのたった一つの厳格なルールは、「masterブランチのものは何であれデプロイ可能である」となる。非常にシンプルであり、GUIプログラムからも問題なく使えるのがメリットである。
GitLab flow
GitHub Flowはデプロイ、環境、リリース、インテグレーションの問題については触れられていない。これらの問題を解決するために提案されるのが、GitLab Flowである。GitLab flowは GitHub Flowと同様に、masterと機能追加用のブランチを持つ。これらに加えて製品ブランチ、環境ブランチ、リリースブランチを持つ。
- 製品ブランチ
- 指定した時間にデプロイするために用いられる。GitHub Flowはリリースする時間をコントロールする必要がないシチュエーションに限定される。
- 環境ブランチ
- 仮にステージング、プレプロダクション、プロダクション環境を有している場合、staging,pre-productionといった環境ブランチを持ち、masterからstaging、stagingからpre-production、pre-productionから製品ブランチへとデプロイする。
- リリースブランチ
- リリースされたソフトウェアに対して別のプロジェクトとして開発を進める必要がある場合の為に、複数のリリースブランチを持つ。これらはmasterから切り出した安定したブランチである。これにより、短時間で複数のリリースブランチに対してバグフィックスを適応することができる。
GitLab Flowは、環境に合わせて柔軟に対応が可能である。
最後に
開発環境、ブランチモデルが固まり、もう少しでテスト的に運用となる。より安定したシステムとして運用できるよう検討していきたい。
間違っている点やこうした方がいいという点があれば、連絡お待ちしております。