WEB+DB PRESS plusシリーズチーム開発実践入門
──共同作業を円滑に行うツール・メソッド

[表紙]チーム開発実践入門──共同作業を円滑に行うツール・メソッド

紙版発売
電子版発売

A5判/336ページ

定価2,948円(本体2,680円+税10%)

ISBN 978-4-7741-6428-1

電子版

→学校・法人一括購入ご検討の皆様へ

書籍の概要

この本の概要

本書はサービスやアプリケーションを開発する企業において,複数の人たちでチームを組んで開発を進めていく際に必要な考え方や使用するツール,またそれらをうまく使いこなすためのノウハウをまとめています。本書の最初でうまく物事が進んでいない開発現場の一例を示し,その理由と対策についてまとめています。次にその対策に必要なツールである,バージョン管理,チケット管理,CI(継続的インテグレーション),デプロイ,リグレッションテストの章を設け,その使い方と上手な運用ノウハウなどについて現場での経験が豊富な著者が解説しています。

こんな方におすすめ

  • 新規プロジェクトを始める予定のプロジェクトマネージャー,スクラムマスター
  • 最近のWebサービス開発に役立つツールを知りたい方

本書に関するお知らせ

本書の公式タグは#チーム開発実践入門です。

本書に関連する記事を公開しております。

この書籍に関連する記事があります!

はじめに
本書は「チーム開発実践入門」です。読者のみなさんの中にはよくご存じの方も多いかとは思いますが,チーム開発というのは複雑で難しいものです。
チーム開発を円滑に行うには
本誌の読者の中にソフトウェアやサービスの開発を仕事にしている方もいるかと思います。

目次

第1章 チーム開発とは

1.1 1人だけでも開発はできる

1.2 チーム開発で直面する課題

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

1.4 本書の構成

  • 第2章:ケーススタディ
  • 第3~5章:基礎的なプラクティス
  • 第6~7章:継続的デリバリーとリグレッションテスト

1.5 本書を読む前の注意点

  • 最適なプラクティスはケースバイケース
  • どのツールを使うかに正解はない

第2章 チーム開発で起きる問題

  • 2.1 ケーススタディの前提

プロジェクトの前提条件

2.2 ケーススタディ(1日目)

  • 問題1:重要なメールが多すぎて優先順位を決められない
  • 問題2:検証用環境がない
  • 問題3:別名フォルダでブランチを管理している
  • 問題4:データベースの再作成が困難

2.3 ケーススタディ(1日目)における問題点

  • 問題1:重要なメールが多すぎて優先順位を決められない
    • メールの件数が多いために重要なメールが埋もれてしまう
    • ステータス管理ができない
    • 一覧性,検索性が弱い
    • メールでプロジェクトを管理することの課題
  • 問題2:検証用環境がない
  • 問題3:別名フォルダでブランチを管理する
  • 問題4:データベースの再作成が困難

2.4 ケーススタディ(2日目)

  • 問題5:起動するまで壊れていることに気づかない
  • 問題6:他メンバーの修正を上書きして消してしまう
  • 問題7:自信を持ってリファクタリングできない
  • 問題8:バグの修正時期がわからず,デグレードも追跡できない
  • 問題9:ブランチ・タグを活用できていない
  • 問題10:テスト環境や本番環境では動かない
  • 問題11:リリースが複雑で手順書が必要となる

2.5 ケーススタディ(2日目)における問題点

  • 問題5:起動するまで壊れていることに気づかない
  • 問題6:他メンバーの修正を上書きして消してしまう
  • 問題7:自信を持ってリファクタリングできない
  • 問題8:バグの修正時期がわからず,デグレードも追跡できない
  • 問題9:ブランチ・タグを活用できていない
  • 問題10:テスト環境や本番環境では動かない
  • 問題11:リリースが複雑で手順書が必要となる

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

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

2.7 本章のまとめ

第3章 バージョン管理

3.1 バージョン管理システム

  • バージョン管理システムとは
  • バージョン管理システムを使うとなぜ便利なのか
    • 変更内容という最も基本的な記録が残る
    • バージョン間の差分を簡単に確認できる
    • 間違って他人の変更を上書きしないで済むしくみがある
    • ロックモデルとマージモデル
    • 任意の時点まで巻き戻すことができる
    • ファイルベースとチェンジセットベース
    • 複数の派生を作ることができる,ある時点での断面を保存できる

3.2 バージョン管理システムの移り変わり

  • バージョン管理システムがない時代(1970年代以前)
  • RCSの時代(1980年代)
  • CVSの登場(1990年代)
  • VSS,Perforceなど商用ツールの登場(1990年代)
  • Subversionの登場(2000年代)
  • 分散バージョン管理システムの登場(2005年以降)
  • 番外編:GitHubの登場
  • バージョン管理システムの導入状況

3.3 分散バージョン管理システム

  • 分散バージョン管理システムを使うべき5つの理由
    • リポジトリの完全なコピーをローカルマシンに持つことができる
    • 動作が速い
    • 一時的な作業の履歴管理が容易である
    • ブランチ,マージが手軽にできる
    • 場所を選ばないコラボレーションが可能
  • 分散バージョン管理システムのデメリット
    • 真の意味では最新バージョンはシステム上存在しない
    • 真の意味ではリビジョン番号はない
    • ワークフローが柔軟に設定でき過ぎるため混乱しやすい
    • 考え方に慣れるのに時間がかかる

3.4 バージョン管理システムをどう使うべきか

  • 前提
  • バージョン管理システムで管理すべきもの
    • ソースコード
    • 要件書,設計書などのドキュメント
    • データベーススキーマ・データ
    • 設定ファイル
    • ライブラリなど依存関係定義

3.5 Gitを使ったスムーズな並行開発

  • ブランチの使い方
    • ブランチとは
    • リリースブランチとは
    • クローンとブランチの作成
    • コミットとコミットログ
    • ブランチの切り替え
    • バグ修正後のコミット
    • masterへのマージ
    • masterへのPush
    • ブランチの使い方のまとめ
  • タグの使い方
    • タグとは
    • タグの作成
    • タグの確認
    • タグの取得
    • タグ名とブランチ名を同一にするのを避ける
    • タグの使い方のまとめ
    • Detached HEADとは

3.6 Gitを使った開発フロー

  • Gitを使ったワークフローのパターン
    • 中央集権型ワークフロー
    • GitHub型ワークフロー
  • ブランチ戦略のパターン
    • git-flow
    • github-flow
    • 筆者の事例(折衷案)
  • 最適なフローとブランチ戦略は現場によって異なる

3.7 データベーススキーマとデータの管理

  • データベーススキーマを管理する必要がある理由
    • データベース管理者の変更管理を任せた場合
    • 共有データベースでスキーマを変更する場合
  • データベーススキーマをどのように管理すればよいか
    • バージョン管理に必要な要件
    • データベースマイグレーションとは
    • データベースマイグレーションの機能
  • データベースマイグレーションツール
    • Migration(Ruby on Rails)
    • south(Django)
    • Migrations Plugin(CakePHP)
    • Evolution(Play Framework)
  • 具体的な使い方(Evolution)
    • 規約
    • SQLファイルの適用
    • 開発者間でのスキーマの同期
    • 不整合の管理
  • データベースマイグレーションの注意点

3.8 設定ファイルの管理

3.9 依存関係の管理

  • 依存関係解決システム
    • JVM系言語
    • スクリプト系言語
    • 依存関係を管理するメリット

3.10 本章のまとめ

第4章 チケット管理

4.1 チケット管理システム

  • プロジェクトがうまく回らない理由
  • 紙やメール,Excelでタスク管理をすることの問題点
  • チケット管理システムの導入メリット
    • タスク管理をするための基本機能がある
    • 一覧性,検索性が高い
    • 情報の一元管理と共有が可能である
    • レポーティングに利用できる
    • 他システムとの連携が可能,拡張性がある
  • チケット駆動開発とは
    • チケット駆動開発の具体的手順
    • チケット駆動開発を徹底する場合

4.2 主なチケット管理システム

  • OSS製品
    • Trac
    • Redmine
    • Bugzilla
    • Mantis
  • 商用製品
    • JIRA
    • YouTRACK
    • Pivotal Tracker
    • Backlog
    • GitHub
  • ツール選定のポイント
    • チケット管理システムの応用事例

4.3 チケット管理システムとバージョン管理システムの連携

  • 連携によって実現する機能
    • コミットからチケットへのリンク
    • チケットからコミットへのリンク
    • コミットと同時にチケットのステータスを変更する
  • 連携の設定方法
  • GitHub
    • GitHubのissue
    • Service Hooks
    • GitHubとPivotal Trackerの連携
    • GitHubとJIRAとの連携
  • Trac/Redmine
  • Backlog
    • BacklogのGitとの連携
    • BacklogとGitHubの連携
  • Git自身の用意するHookを使う方法

4.4 新機能の開発,バグの修正時のワークフロー

  • ワークフロー
    • ①チケットの起票
    • ②担当者のアサイン
    • ③開発
    • ④コミット
    • ⑤リポジトリにプッシュ

4.5 「あのバグいつ直ったの」という問い合わせに答える

  • Pivotal Trackerの例
    • 記憶に残っている文字列で検索
    • 検索
    • チケットからソースコードの変更を探す
  • Backlogの例
    • 検索

4.6 「なぜこんな変更が入ったんだろう」という疑問を解決する

4.7 本章のまとめ

    • チケット管理とバグ管理,要求管理について

第5章 CI(継続的インテグレーション)

5.1 CI(継続的インテグレーション)

  • CI(継続的インテグレーション)とは
    • インテグレーション
    • インテグレーションを継続的に行うのがCI
  • 開発をアジャイル化する
    • ウォーターフォール開発の開発フェーズ
    • アジャイル開発の開発フェーズ
  • なぜCIのようなプラクティスが求められるか
    • コストメリット
    • 市場の変化のスピード
    • スピードと品質を両立させるには
  • CIに必要なもの
    • バージョン管理システム
    • ビルドツール
    • テストコード
    • CIツール
  • テストを書くためのフレームワーク
    • テスト駆動開発(TDD)系フレームワーク
    • 振る舞い駆動開発(BDD)系フレームワーク
  • 主なCIツール
    • Jenkins
    • TravisCI

5.2 ビルドツールの使い方

  • 新規にプロジェクトを始める場合
    • プロジェクトのひな型作成
    • 依存関係の定義
    • テストの実行
    • Eclipseへのインポート
  • 既存プロジェクトを自動ビルド可能にする場合
  • ビルドツールのまとめ

5.3 テストコードの書き方

  • CIの対象となるテストの種類
  • テストをいつ書くのか
    • 新規にプロジェクトを始める場合
    • 既存プロジェクトにテストがない場合
    • バグ修正または新機能を追加した場合
  • 厄介なテストをどう書くか
    • 外部とのやりとりがあるテスト
    • モッキングフレームワークを使ってテストする
    • インメモリデータベースを使ってテストする
    • データベース変更管理や設定ファイル管理のテスト
    • UIを伴うテスト
    • 厄介なテストは工数とのトレードオフ

5.4 Jenkinsを使ったCIの実行

  • Jenkinsのセットアップ
    • ネイティブパッケージを使ったセットアップ
  • Jenkinsで何ができるのか
  • ジョブの新規作成
  • ソースコードをチェックアウトする
  • 自動でビルドおよびテストを実行する
    • 定期実行
    • バージョン管理システムをポーリング
    • バージョン管理システムからプッシュする
    • ビルドの記述
  • 結果を集計してレポーティング
  • カバレッジを計測する
    • JUnitXML形式でレポートを出力するのが効率的
    • カバレッジ計測ツール
    • Maven Coberturaプラグインのインストール
    • Java系ライブラリの探し方
    • Jenkinsプラグインの設定
  • 静的解析をする
  • 通知の設定をする

5.5 CIの運用

  • ビルドが壊れたらどうするか
    • Subversionなど中央集権型バージョン管理システムの場合
    • Gitなど分散バージョン管理システムの場合
    • ビルドを壊したときの罰ゲーム
    • テストしてからマージする
  • トレーサビリティの担保
    • ビルドとコミットを関連づける
    • チケット管理と連携する

5.6 本章のまとめ ―― CIによって得られるもの ――

第6章 デプロイの自動化(継続的デリバリー)

6.1 デプロイとはどうあるべきか

  • デプロイの自動化における恩恵
    • 細かくたくさんリリースできればリスクをコントロールしやすくなる
    • フィードバックを早く得られるようになる
    • 組織がスケールする

6.2 デプロイの自動化

  • デプロイの自動化における共通認識
  • デプロイメントパイプライン
    • 自動化によりデプロイの速度を加速させる
    • 誰でもデプロイが行えるようにすることが重要
  • プロビジョニングツールチェーン

6.3 ブートストラッピング(Bootstrapping)

  • Kickstart
    • Kickstartの利用方法
    • 利用する際の注意点
    • Kickstartの設定例
  • Vagrant
    • 開発者ごとに実機を用意することは難しい
    • 仮想環境を利用する際の懸念点
    • Vagrantとは
    • Vagrantのインストールと実行方法

6.4 コンフィグレーション(Configuration)

  • 自動化を行わない場合の問題点
  • Chef
    • Chefの構成
    • ディレクトリ構成とファイル配置
    • node.json
    • setup.json
    • solo.rb
    • default.rb
    • virtualhost.conf.erb
    • Chefの実行方法と実行結果
    • Chefを利用するメリット
    • Chefを利用する際の注意点
    • Chefを利用するタイミング
  • serverspec
    • serverspecとは
    • serverspecのインストール
    • テストファイルの記述方法
    • httpd_spec.rb
    • git_spec.rb
    • serverspecの実行方法と実行結果
    • serverspecのメリット
  • ベストプラクティス(その1)
    • Vagrantfile
    • default.rb
  • ベストプラクティス(その2)
  • 物理サーバがサービス投入可能になるまでの流れを自動化する例
  • リリース作業についてのアンチパターン

6.5 オーケストレーション(Orchestration)

  • Capistrano
    • Capistranoのシステム構成
    • Capistranoのインストール
    • deploy.rb
    • Capistranoの実行方法
  • Fabric
    • Fabric(直列実行)の場合
    • Capistrano(並列実行)の場合
    • ローカルサーバとリモートサーバの操作の違いを理解する
    • Fabricの実行方法
  • Jenkins
    • マスタノードとスレーブノードの連携
    • スレーブノードの追加
    • ジョブの追加
    • ジョブの実行
  • ベストプラクティス
    • JenkinsとFabricを組み合わせる
  • セキュリティについて考慮する
    • 手作業でデプロイするケース

6.6 運用について考慮する

  • サービスを止めないデプロイ方法
  • ブルーグリーンデプロイメント
  • クラウド時代のブルーグリーンデプロイメント
  • ロールバックについての考察
    • 退路は常に用意する
    • データベーススキーマのバージョン管理
    • ロールバックの検証
    • ソース更新のみのリリース時のロールバック
    • データベーススキーマ更新時のロールバック

6.7 本章のまとめ

    • PaaSを利用する手段
  • 第7章 リグレッションテスト

7.1 リグレッションテスト

  • リグレッションテストとは
  • テスト種別の整理
    • チームを支援する技術面のテスト(第1象限)
    • チームを支援するビジネス面のテスト(第2象限)
    • 製品を批評するビジネス面のテスト(第3象限)
    • 技術面のテストを使った製品の批評(第4象限)
  • リグレッションテストの必要性
    • デグレードの発生
    • テストを自動化すべき理由
  • リグレッションテストの自動化で目指すこと

7.2 Selenium

  • Seleniumとは
  • Seleniumの利点
    • 自動化テストケース作成が簡単
    • 多くのブラウザやOSをサポート
  • Seleniumコンポーネント
    • Selenium IDE
    • Selenium Remote Control(Selenium RC)
    • Selenium WebDriver
  • テストケースの作成と実行
    • Selenium IDEのインストールと実行
    • Seleniumのテストケース
    • 良いテストケースとは
    • Selenium Serverを使ったテスト実行
  • Seleniumの実践活用
    • 画面が変更されていないかをテストする
    • Seleniumテストを安定させるためには

7.3 JenkinsとSeleniumの連携

  • JenkinsとSeleniumの連携手順

7.4 Seleniumテストの高速化

  • Jenkinsの分散ビルドでテストの並列実行
    • Jenkinsの分散ビルドの構成
    • 分散ビルドの設定
  • Seleniumテスト並列化の難しさ

7.5 複数のアプリケーションバージョンでのテスト

  • アプリケーションのデプロイ
  • テストケースをバージョン管理システムからチェックアウト
  • Seleniumでのテスト

7.6 本章のまとめ

著者プロフィール

池田尚史(いけだたかふみ)

ソフトウェア開発者。大学卒業後,ITコンサルタントとしてキャリアをスタート。その後コンサルタントからプログラマに転身し,パッケージソフトウェア開発,Webサービス開発を経て,2013年より株式会社ディー・エヌ・エーに所属している。数々の修羅場をくぐってきており,第2章のケーススタディの内容のほとんどは実体験をベースにして書かれていることは秘密である。JavaのWebアプリケーションフレームワークであるPlay Framework1のコミッターでもある。2児の父。第1章~第5章までの執筆と全体の監修を担当。
Twitter:@ikeike443


藤倉和明(ふじくらかずあき)

インフラストラクチャエンジニア。大学卒業後,株式会社シャノンでインフラストラクチャエンジニアとして従事。社内インフラからサービス本番環境まで「インフラ」と名の付くものとセキュリティ全般が守備範囲。数々のアプリケーションのデプロイの自動化を推進してきた実体験を元に第6章を執筆。OpenVZやLXCといったコンテナタイプの仮想化技術が大好物。
Twitter:@fujya


井上史彰(いのうえふみあき)

株式会社シャノンにてソフトウェアエンジニア,QAエンジニアを経て,同社子会社である中国法人の総経理(現職)。開発の経験を活かして効果的で効率的な自動テストの実践に従事。第7章を執筆。
E-mail:fu.inoue@gmail.com