GeekFactory

int128.hatenablog.com

ビルドツールによる開発プロセスの改善と効果

世の中にいくら便利なツールがあっても、それを使うのは人です。ツールを導入するだけでは開発プロセスは変わりません。開発プロセスを変えるには、前例や慣習にしがみつく人や組織のリテラシーを変えていく必要があります。そういうレガシーな人たちと闘うための論理が必要だと思います。それはどの現場でも*1通用する力になると思います。

前置きが長くなりましたが、ビルドツールを導入して開発プロセスを改善するにあたって嬉しいことを挙げてみました。想定問答集です。コメントいただけると嬉しいです。

ソースコード管理ツール

Subversion, Git, Mercurial, Team Foundation Serverなど。

導入してうれしいこと

開発者はソースコードを変更したらソースコード管理システムにコミットする。ソースコード管理システムは変更の差分を反映する。他人の変更と競合した場合は通知される。

  • ソースコードの一貫性を保てる。
  • 複数人で協調作業できるようになる。
ないと困ること

共有フォルダに日付を付けて定期的にコピーするとか。

  • 他人が変更した内容を上書きするおそれがある。
  • 変更履歴を一覧で見たり、差分を確認したりするのが困難。
  • 変更履歴にコメントを残せない。

依存関係管理ツール

Maven, Ivy, Gradle, Sbtなど。

導入してうれしいこと

ビルドツールが依存ライブラリを自動的にダウンロードしてIDEに設定してくれる。依存関係はDSLで定義する。

  • 依存ライブラリを統一できる。
  • 開発者が依存ライブラリをダウンロードして管理する手間を省ける。
ないと困ること

ライブラリ管理担当者が依存ライブラリをダウンロードしてリポジトリや共有フォルダに保存する。開発者は依存ライブラリを自分のPCにコピーする。もしくは、開発者が自分で依存ライブラリをダウンロードしてくる。

  • 環境によって必要なライブラリがない、バージョンが違うなどの差異が発生する。
    • AさんのPCで動くけどBさんのPCで動かないといった事象が起こる。
  • 開発者の手間が増える。

継続的インテグレーションツール(ビルドツール)

Maven, Gradleなど。ワークフローを制御するのはJenkins, Team Foundation Serverなど。

導入してうれしいこと

開発者がソースコードに変更を加えるたびにビルドやテストを実行するため、問題に素早く気付くことができる。また、ビルドやテストを実行するサーバを本番環境相当にすることで、本番環境(検証環境)で動かないリスクを軽減できる。

  • 問題を早期に発見できる。
  • 本番環境で動かないリスクを軽減できる。
  • 作業品質の平準化。
ないと困ること

ビルド担当者が定期的に自分のPCでビルドやテストを実行し、問題がある場合は会議で報告する。もしくは、開発者がたまに全体をテストしてエラーに気付く。

  • 問題の発見が遅れる。
  • 環境によってビルドやテストが通らないといった差異が発生する。
    • AさんのPCで動くけどBさんのPCで動かないといった事象が起こる。
    • 本番環境にデプロイしたら動かないといった事象が起こる。
  • ビルド担当者がいない場合は動作確認やリリースができない。

継続的デリバリーツール(デプロイツール)

Cargo, Capistranoなど。ワークフローを制御するのはJenkins, Team Foundation Serverなど。

導入してうれしいこと

ワンクリックで自動的に成果物(WARファイルとか)をサーバにデプロイできる。

  • リリース作業の省力化。
  • 作業品質の平準化。
ないと困ること

リリース担当者がビルド担当者から成果物(WARファイルとか)を受領し、手順書にしたがってサーバにデプロイする。

  • 手順を間違えるおそれがある。オペミス怖い。
  • リリース担当者がいない場合はリリースできない。

成果物管理ツール

Nexus, Artifactoryなど。

導入してうれしいこと

プロジェクトの成果物をバージョン管理できる。また、インターネット上で公開されていないプロプライエタリなライブラリを統合管理できる。

ないと困ること

プロジェクトの成果物(WARファイルとか)は共有フォルダに日付を付けて保存する。また、プロプライエタリなライブラリは開発者が自分で管理する。

補足

ぶっちゃけプロジェクトの成果物は共有フォルダでもいい気がします。NexusやArtifactoryがあってうれしいことは以下に集約されると思います。

*1:もちろん程度問題はあります。ソースコードを共有フォルダでいじってるとか危険な場所もあるわけで、そういう場所はなるべく(ry