あくまで個人的見解です。
開発時に使用したいミドルウェア
現在使用している開発環境は、
仮想マシンにインストールしたLinux上でDockerを稼働し、
主に以下のコンテナを稼働している。
- OpenLDAP：アカウント管理
- Gitlab：バージョン管理
- Subversion：バージョン管理
- RedMine：チケット管理
- Jenkins：自動デプロイ
- smtp4dev：ダミーのメール送信サーバ
- Zabbix：サーバ監視
このうち、
構成管理にはGitLabとSubversionを使い分けるようにしており、
GitLabはソース管理に、
Subversionはドキュメント管理に使用している。
ドキュメントまで履歴管理をする必要性を感じない場合は、
ファイル共有でも問題ないが、
特に設計書や複数人が書きあう可能性が高いメッセージ一覧など、
主に若年層が不慣れのためにうっかり消してしまうことも実際に何度もあったため、
機械的に履歴管理した方が、
最近よく聞く心理的安全性の面でもメリットは非常に大きいと思われる。
GitとSVNを共存する理由
これはソース管理とドキュメント管理で、
性質が大きく異なると判断したためである。
ソース管理においては、
案件（チケット）ごとに枝（ブランチ）を張り、
リリース後に対応内容を本線（トランク）にマージする手法を取り、
ソースのほとんどがテキストファイルであるからこそ、
差分を見てマージすることが比較的容易である側面がある。
ここにドキュメントまで含めてしまうと、
差分を突合することが一段と煩雑になってしまう可能性が非常に高い。
一方、
ドキュメントのほとんどはバイナリファイルであることが多い。
バイナリファイルの差分突合には余程の習熟度が必要であり、
ジュニアＰＧなどヒューマンエラーを考慮すると、
ロックを使用して入出庫を行った方が安全である。
またドキュメントなら、
印刷範囲の欄外で履歴管理（案件履歴）のコメントを残しやすい。
以上から、
テキストベースであるソース管理にはGitLabを、
バイナリベースであるドキュメントにはSubversionを使用している。
また各リリースタイミングでSubversion内のリリース資材をGitLabの本線から更新し、
そのSubversion内のリリース資材を本番反映するようにすれば、
本番環境にある各資材のタイムスタンプも一貫性が保たれるメリットも生じている。
本線とブランチ
本線は、
紛れもなく「ＦＩＸした資材の一式」を管理するものである。
変更要望が生じた際に本線のソースをそのまま変更してしまうと、
案件が五月雨にリリースされる場合、
リリース対象のソースを管理することが非常に難しくなる。
そのため、
案件ごとに作業ブランチを作成し、
テスト完了を経てリリースし本線にマージする手順をとることが多い。
作業ブランチで変更内容を実装するが、
作業完了後はテスト環境でテストを行い、
検証環境でユーザの最終確認後、
本番環境に反映することとなるが、
障害時の切り戻しも考慮する必要がある。
各環境に反映するため、
各環境用のブランチも作成しておけば管理が容易になる。
テスト環境向けにはdevelopブランチ、
検証環境向けにはstagingブランチ、
リリース用にはreleaseブランチを作成し、
段階的にマージしていく。
【具体例】
- RedMineなどで発番されたチケットIDに合わせて作業ブランチを作成する。
- 作業ブランチで改修後にローカルで疎通確認を行い、
テストブランチ（develop）にマージリクエストする。 - ソースレビューがOKであればテストブランチ（develop）にマージする。
- JenkinsなどCIツールでdevelopブランチをテスト環境に反映する。
- テスト環境で単体テスト・結合テストを行いテスト結果のレビューを受ける。
- レビューOKなら、次は検証ブランチ（staging）にマージリクエストする。
- 検証環境は本番環境とほぼ同等の環境とするため、
設定ファイルの整合性なども含めてレビューする。 - テスト環境と同じく、
JenkinsなどCIツールでstagingブランチを検証環境に反映する。 - 検証環境でシステムテスト・受入検査を経て、
リリース判定がOKｎならreleaseブランチにマージする。 - releaseブランチもJenkinsなどCIツールでビルドするのであるが、
この時はSVNのリリース資材にコミットし、
ソース管理とは別にリリースセットとして履歴管理を行う。 - 本番機からSVNの本番リリース資材を差分比較用フォルダに更新（svn update）する。
- 本番ディレクトリと差分比較フォルダをWinMergeなどで差分比較しながら、
本番リリース作業を行う。 - 安定稼働が確認されたのち、晴れてreleaseブランチを本線にマージする。
