ビルドツールによる開発プロセスの改善と効果
世の中にいくら便利なツールがあっても、それを使うのは人です。ツールを導入するだけでは開発プロセスは変わりません。開発プロセスを変えるには、前例や慣習にしがみつく人や組織のリテラシーを変えていく必要があります。そういうレガシーな人たちと闘うための論理が必要だと思います。それはどの現場でも*1通用する力になると思います。
前置きが長くなりましたが、ビルドツールを導入して開発プロセスを改善するにあたって嬉しいことを挙げてみました。想定問答集です。コメントいただけると嬉しいです。
ソースコード管理ツール
Subversion, Git, Mercurial, Team Foundation Serverなど。
導入してうれしいこと
開発者はソースコードを変更したらソースコード管理システムにコミットする。ソースコード管理システムは変更の差分を反映する。他人の変更と競合した場合は通知される。
- ソースコードの一貫性を保てる。
- 複数人で協調作業できるようになる。
ないと困ること
共有フォルダに日付を付けて定期的にコピーするとか。
- 他人が変更した内容を上書きするおそれがある。
- 変更履歴を一覧で見たり、差分を確認したりするのが困難。
- 変更履歴にコメントを残せない。
依存関係管理ツール
Maven, Ivy, Gradle, Sbtなど。
継続的インテグレーションツール(ビルドツール)
Maven, Gradleなど。ワークフローを制御するのはJenkins, Team Foundation Serverなど。
継続的デリバリーツール(デプロイツール)
Cargo, Capistranoなど。ワークフローを制御するのはJenkins, Team Foundation Serverなど。
ないと困ること
リリース担当者がビルド担当者から成果物(WARファイルとか)を受領し、手順書にしたがってサーバにデプロイする。
- 手順を間違えるおそれがある。オペミス怖い。
- リリース担当者がいない場合はリリースできない。
成果物管理ツール
Nexus, Artifactoryなど。
導入してうれしいこと
プロジェクトの成果物をバージョン管理できる。また、インターネット上で公開されていないプロプライエタリなライブラリを統合管理できる。
ないと困ること
プロジェクトの成果物(WARファイルとか)は共有フォルダに日付を付けて保存する。また、プロプライエタリなライブラリは開発者が自分で管理する。
補足
ぶっちゃけプロジェクトの成果物は共有フォルダでもいい気がします。NexusやArtifactoryがあってうれしいことは以下に集約されると思います。