Git
GitHub
Jenkins
CI

『チーム開発実践入門』を読んだメモ

More than 3 years have passed since last update.

『チーム開発実践入門』を読んで

結論から言うと、今自分が知りたかったことに対して明確な答えを出してくれた、読んだタイミングがバッチリな出会いでした。
「知りたかったこと」というのは、研修が終わって出された現場で、Jenkinsをはじめとするビルド・デプロイ環境の全体感がどうなっているのか
しっかりと把握したかった、ということです。

この本では、以下について説明しています。
それぞれのツールやミドルウェアの詳細な説明が書かれているというよりも、
継続的改善を実現するための開発フローの全体感をしっかり把握することができます。

  • バージョン管理
  • Git
  • GitHub
  • チケット管理
  • CI
  • Jenkins
  • ビルドツール
  • テストコード
  • デプロイ
  • Vagrant
  • Chef
  • serverspec
  • Capistrano
  • リグレッションテスト
  • Selenium

なので、この本は、こんな人におすすめです。

  • 新人で研修が終わって現場に出たけど、JenkinsやらSeleniumやらいろいろなツールがどんな風に使われているのか全体像を掴みたい人
  • 部やグループの開発環境整備の担当になったけれど、何から手を付けたらいいかわからずとりあえず全体感を掴みたい人
  • ベンチャーでデプロイ環境やバグ管理のノウハウが蓄積されていない現場で、チームの状況に照らしあわせた環境を整えたい人

著者の方の実際の経験談を踏まえたリアリティのあるケーススタディが参考になりました。
経験のあるプログラマなら「あーそれね、あるある」という感じで読まれるのでしょうか。
自分の場合は、「そんなこともあるんだ!」という意味で新鮮な視点も「これ前のプロジェクトに似ているな」という既知の視点も
両方ありました。

本書の優れている点は、そういった「よくありがちな課題」に対して、「なぜ課題なのか」をケーススタディから
汎用化したうえで、それに適するツールを紹介していることです。
「詳細なツールの使い方は、他書籍や公式HPをどうぞ」的な記述が多いので、実際に導入したり学習したりする場合には
他のリソースを参照にすることになるかと思いますが、全体像や課題に対するとっつきを知るためには適書だと思います。

なお、以下で抜き出したのは主観的に抜き出したほんの一部です。

どのように課題に立ち向かうか

・「何を」「いつまでに」「誰が」実行するのか、「何が」できたら「完了」なのかを管理・共有すること
・ソースコードを始めとする成果物をチームで共有すること
・成果物の変更を管理し、成果物が壊れないように保ちつつ、各メンバーが並行作業できるようにすること
・プロジェクトで得られた知識をチーム間で共有すること
・チームで開発したソフトウェアがいつでも正しく動作することを証明すること
・誰がやっても間違いなく開発・テスト・リリースができるように作業を自動化すること

理想的なプロジェクトとは

ケーススタディを踏まえたうえで、理想的な開発フローの一例を紹介。

・チケット管理システムに課題などが集約されている
・できる限りバージョン管理システムを利用する
・繰り返し再検証可能なCIシステムを用意する
・環境の影響を最小限に止め、常にリリース可能にしておく
・すべてを記録して追跡可能にする

分散バージョンシステムのメリット/デメリット

メリット:

・リポジトリの完全なコピーをローカルマシンに持つことができる
・ネットワーク通信のボトルネックが発生しないため、動作が速い
・中央集権型バージョン管理システムと異なり、全体に影響を与えないままローカルマシンでのコミットが可能なため、一時的な作業の保存も容易で開発効率が向上する
・したがって、ブランチ/マージが手軽にできる
・場所を選ばないコラボレーションが可能

デメリット:

・真の意味では最新バージョンはシステム上存在しない
・真の意味ではリビジョン番号はなく、ひとつひとつのチェンジセットにGUID(Globally Unique Identifier)が振られており、新旧ではなくチェンジセットをユニークに管理している(マージの容易さというメリットにもなる)
・ワークフローが柔軟に設定できすぎるため混乱しやすい
・考え方になれるのに時間がかかる

分散バージョンシステムで管理すべきもの

名著『達人プログラマー―システム開発の職人から名匠への道』より:

それ以外にも、ソースコード管理システムの傘の下にプロジェクト全体を置くということは、途方も無く大きなメリットが隠されているのです。そのメリットとは、成果物のビルド作業を自動的に、かつ繰り返し可能なものにできるというものです。

・ソースコード
・要件書、設計書などのドキュメント
・データベーススキーマ、データ
・ミドルウェアなどの設定ファイル
・ライブラリなどの依存関係

チケット管理システム

プロジェクトがうまく回らない理由

・目標が間違っている
・見積もりが不正確で納期が非常に短く、要因が不足している
・プロジェクトの終わりが定義されていない
・メンバーのモチベーションが上がらず進捗しない
・プロジェクトの見える化ができていない
・タスクの整理、進捗の管理、情報の共有などができていない

チケット駆動開発

TiDD = Ticket Driven Development

・あくまで方法論であり、ツールの使用を前提としているわけではない
・コミットログとチケットが関連付けられていること
・GitHubならService Hooksなどが使える

チケット管理とバグ管理、要求管理のスコープについて

Scrumの用語を用いて説明

・エピック(大きな要望、部署横断の課題)
・ストーリー(具体的な要望、機能要求や仕様に近いレベル)
・タスク(作業)
・バグ(障害対応)

主なビルドツールまとめ

Title Description
make 古典的なビルドツール。Makefileという設定ファイルをもとにビルド。
SCons Python製のmake代替ツール。SConstructというPythonで書かれた設定ファイルを使ってビルドする。V8のビルドにも使われている。
Ant Java製のビルドツール。build.xmlに設定を記述。Mavenと比べると手続き的にビルド手順を書くため、煩雑だが柔軟性は高い。
Maven Java製のプロジェクト管理ツール。pom.xmlに設定を記述。CoC(Convention over Configuration)という考え方に則って作られたツール。ビルドの他にもプロジェクトサイトの生成やテストの実行、デプロイなどができる
Gradle 近年Java界隈で注目を集めている新しいビルドツール。GroovyというJVM上で動作するスクリプト言語で記述するため、XMLより可読性も自由度も高い。
Rake Rubyのビルド製ツール。Rakefileを使う。

プロビジョニングツールチェーン

・Orchestration : Capistrano, Fabric : アプリケーションサービスのデプロイ自動化
・Configuration : Puppet, Boxen, Chef : システム設定
・Bootstraping : Vagrant, Kickstart, AWS, Cobbler, VMWare : クラウドまたはVMイメージの起動/OSのインストール