はじめに
オンプレミスの資産管理の方法として、GitLabなど利用している企業の方も多いのではないでしょうか? 今回はGitLabの活用方法についていくつかご紹介したいと思います。
資產管理
一番スタンダードな使い方です。
ソースコードの管理の他、設計書などの管理も行うとよろしいと思います。
そうすることで、「このリビジョンではこうゆう設計である。」などが明確になるため、 バグを検出した際に、どのリビジョンから発生したのか?設計バグなのか?いつその設計バグが盛り込まれたのか などが明確になります。
なお、ドキュメント類に関してはどの形式で作成していくか?というのは好みがあります。
-
差分を見ることが多い場合
マークダウンなどテキストファイルでの作成をお勧めします。
ただし、表や図などを入れ込む際、外部ツールで作成したものを埋め込んだりというのをやることが多く、 表現の幅にも若干疑があります。 -
差分を見ることはほとんどなく、図・表をきれいに作りたい場合
Officeのファイルをそのまま資産管理に入れてしまうことをお勧めします。 なんだかんだでいろいろと表現しやすい点が魅力です。
デプロイ (構成)
例えばサーバーに入っているディレクトリ構成などを他に移行したいときにお勧めです。
もちろん仮想化した基盤であれば他にもやりようがありますが、アプリケーション領域の構成を作るのは 管理部署が異なるなどであれば活用するケースはあると思います。
同じ構成をpullするだけで作れますし、他にもセカンダリのサーバーに変更を適用したい場合などにも
コマンドーつで適用できますので構築・変更時の作業漏れ・ミスを軽減することにもつながります。
CICD
登録された資産がビルドを通るか検査することができます。
これにより、いざリリース時にビルドが通らないのだが・・・といったことを防ぐことができますし、ワーニングなど開発担当が見過ごしているものなど検知することもできます。
静的解析などを自動で通すこともできますので、マージ時に静的解析を通して・・・などの作業も不要となります。
他、自動テストのコマンドを実行することもできますので、デグレードの検出などにも有効です。
一方、上記についてはサーバーの環境(各種ミドルウェアなどのバージョン)と揃える必要があります。
その為、GitLabサーバーが実行環境のサーバーと同居であれば良いのですが(サーバーのリソースを共有するためお勧めしませんが)、ほとんどの場合、複数のプロジェクトの構成管理をすると思いますので、実行自体は検証環境上で行うなどした方が無難ではないかなと思います。
ソースコードレビューの強制化
masterはレビューアのみ適用可能で、マージする際にレビューアがレビューするというルールにて運用する ことでレビューを強制化できます。
もちろんレビューアが手を抜くと台無しですが、知らない変更が勝手に組み込まれているというのは防ぐ ことができます。
アジャイル開発での活用
issue及びマイルストーンを使用することで、1スプリントごとにやることとその進捗管理をすることができます。
筆者はあまり使ったことはありませんが、アジャイル開発のPMをする際にはぜひ使いたい機能であると 考えています。
終わりに
まだまだ使いこなせていない機能はたくさんありますが、構成管理に困っている、CICDを実現したい、 アジャイル開発の管理ツールが欲しいなど検討中の方には多少ご参考になるのではないでしょうか? わたしはwincvs、svnと使ってきて、gitを使う際に若干戸惑いがありましたが、1年ほど使用すると慣れてくると思います。