「チーム開発実践入門」勉強会

2014-05-01 Yu ISHIKAWA

+ 知っている単語はいくつありますか？ – 単体テスト or TDD (Test Driven Development) – 継続的インテグレーション – 継続的デリバリー – Git – Jenkins

+ タイトル：チーム開発実践入門 + 発行所：技術評論社 + 内容：“複数の人たちでチームを組んで開発を進めていく際に必要な考え方や使用するツール、またそれらをうまく使いこなすためのノウハウをまとめて”ある

+ 世の中こんなに便利になっているんだ，モダンな開発ってこういう風なんだというのを知ってください – 細かいツールの使い方や運用フローの解説はしません

+ チーム開発に役立つツールや方法論に唯一絶対の正解はありません + 企業規模，製品規模，チーム規模によって最適な解決策はことなります + しかし，紹介する内容には，効率的に仕事をする上で様々なヒントを与えてくれると思います

+ ケーススタディ + バージョン管理 + チケット管理 + （５〜10分休憩） + 継続的インテグレーション + 継続的デリバリー + まとめ

+ ケーススタディ + バージョン管理 + チケット管理 + 継続的インテグレーション + 継続的デリバリー + まとめ

+ デスマーチになっている Web アプリ開発プロジェクトに途中でアサインされた A さんの話 + プロジェクトの前提 – システム  Web アプリケーション  DB – 開発のみならずリリース後のバージョンアップや運用なども継続的に行う

Aさんほかの開発者タスク管理はメールやエクセルテスト担当者本番サーバソースコード用共有フォルダソースコードはフォルダ名を変えることで管理各自の環境はバラバラに構築検証用のステージング環境はない手作業でリリース知識の共有が行われていないバグ報告者

+ １日目重たい気持ちで出社したAさんが早速メールを開くとつぎのような４件のメールが… – 【重要】エラーが出ています．すぐに対応してください！ – 【至急】本番環境で重大な障害が発生！対応お願いします – 【依頼】軽微のレイアウトズレが起きているようです – 【本番障害】【重要】【至急】【即対応】お客様からクレームを頂いています．いますぐ対応してください + しかし，アサインされたばかりのAさんどれから対応すべきかの優先度が付けられません + 周りの人に聞きつつ，全部読んで対応することにします

+ 報告されたエラーが本当に発生するのかを試そうとしますが，本番での検証をするのには重大な障害もありました + しかし検証環境がないためすぐに試すことができません + しかたがないので，手元の自分のマシンに検証用の環境を構築することにしました + 残念ながら，環境を構築するための手順がまとまっていません！ + しかたがないのでほかのメンバーにひとつひとつ聞きながら構築します

+ なんとかサーバ構築が終わり，要約アプリのソースコードとDBの構築をしようとします + ソースコードがディレクトリ名を変えることで管理されているため，いま本番で動いているのがどのソースコードなのかわかりません – app_latest – app_new – app_current – app_lastest2 + DB の構築を試みるもスキーマが管理されていないので，本番サーバのスキーマを調べて自分で再構築しました + アプリの起動とDBの構築が終わるもうまく再現することができません

+ ようやく本番と「同じと思われる」環境を構築して，バグの修正に入ります + Aさん一人では対応できないので，それぞれ４件のバグを４人で手分けして行うことにしました + 急いで対応している中，バグ報告者から電話での状況確認の問い合わせが頻繁に来て，作業に集中できません + なんとか，それぞれの環境でなんとか各自担当したエラーを修正して，手作業で再現しないことを確認し，共有フォルダに各自同期をとって１日目を終えました

+ ２日目の朝，テスト担当者からAさんに４件の修正のうち３件しか直っておらず，昔直したはずのバグも発生しているという連絡が入りました + 調べてみると，４件のバグで手分けした修正でお互いの変更を上書きしてしまったようでした + またテスト担当者の環境とAさんの環境が違うため発生している問題もあったようです + 問題の箇所を修正しなおし，１日目に報告されたバグの対応を終えました

+ 昔直されたバグについての修正をしようとします + しかし，途中からアサインされたAさんには昔どのようなやりとりがなされて，どのように修正されたのかをメールでタスク管理されていたため追跡することができません + ほかの人に調べてもらい，どういう経緯かの把握をすませ，要約バグ対応に入ります + まずバグが再現するのかを手元のマシンで確認をし，ソースコードのどこに問題があるのか調査をはじめます + ソースコードがバージョン管理されていないので昔の修正を確認することができないため，自分なりに変更を加えバグが再現しないことを確認しました

+ なんとかテストもクリアし，修正したものをリリースします + いつもリリースしている人が休みなので，手順書にしたがって手作業で行います + ソースコードのデプロイだけでなく，DDLや依存するライブラリ，設定ファイルの反映など複雑なようです + リリースしてみるも，作業にもんだいがあったのか本番環境にうまく反映することができません + デプロイする前の状態に戻すやり方がわかりません + 参考にしている手順書のバージョンが古かったらしく，なんとか最新の手順書を確認しながら無事リリースができました

+ メールでのタスク管理 – タスクの優先順位がわからないため，どれから対応すべきかがわからない – タスクのステータス管理ができないため，いちいち問い合わせに対応しないといけない – ほかのメールと交じるため一覧性が悪い – 途中から加わったメンバーが過去の状況を確認できないなど検索性が悪い + 検証環境（ステージング環境）がない – 報告されたバグを速やかに検証する環境がないため，ことあるごとに手元に環境を構築する必要がある + メンバーそれぞれがバラバラに環境を構築している – 統一した環境を構築する仕組みが無いために，お互いの環境を都度揃えるためのコストがかかる

+ ソースコードがバージョン管理されていない – 互いの変更を上書きしてしまう – お互いの差分が衝突したときの解決ができない – 過去のバグ修正の履歴が負えない + DBの再生成が困難 – アプリを起動するために必要な DDL やデータがきちんと管理されていないため，都度本番のデータをダンプして持ってくるなどの無駄が発生 + 自動テストがないためデグレーションを検知できない – 既存の昨日に影響を与えていないかなどのチェックを手作業でやったりしていると，抜け漏れが発生するし，コストが高い

+ リリース手順が手作業あるいは複雑 – リリース作業を手作業でやるとそのための修正コスト，メンテナンスコストが高くなる + 本番環境で動かない – 設定の反映を間違えるなどにより，本番で動かないリスクが伴う

+ タスクの管理は，タスク管理用ツールを活用されている – バグ報告者はタスクのステータスを確認することで問い合わせコストがなくなるなど + ナレッジは wiki にまとまっている – 新しいメンバーも簡単に検索することができて，スムーズにプロジェクトに必要な知識を身につけられる – ひとの時間を奪わない + 検証環境が用意されている – 報告されたバグをすみやかに再現できる + 確認作業，テストがすべて自動化されている + 各自の環境を自動的に整える仕組みがある – 各自の環境が異なっているために起きる問題がない + ソースコードは適切にバージョン管理されている – 過去の履歴を追跡できる – 互いに上書きするリスクを抑えられる + 自動的にリリースする仕組みがある – 間違えたり忘れたり，また属人性を排除するために手作業はなくす

+ 自動化 + 追跡可能性 + 再現性 + {属人性,暗黙知}の排除 + 人間は間違えかつ忘れる

+ あるファイルをいつ，だれが，なにを，どのように変更したかの履歴を記録として管理するシステム + 導入メリット – 変更内容という最も基本的な記録が残る – バージョン間の差分が簡単に確認できる – 間違って他の人の変更を上書きしないで住む仕組みがある – 任意の時点まで巻き戻すことができる + ツール例（SVN の時代は終了しました） – Git（分散管理）, Github などが有名 – SVN: Subversion （中央管理）

+ 「管理できるものはすべて VCS で管理すべき」 – ソースコード – テストコード – 要件書，設計書などのドキュメント – データベーススキーマ，システムを構築するのに必要なデータ – ミドルウェアなどの設定ファイル – ライブラリなどの依存関係の定義 + 注意：VCS 管理者によっては Excel などのバイナリファイルはコミットされたくない人もいるのでルールに合わせる

+ 一時的な作業の履歴管理が容易 – 中央管理型と異なり，全体に影響を与えないままローカルマシンでのコミットをすることが可能なため，一時的な作業の保存も容易で開発効率が向上 + 場所を選ばないコラボレーションが可能 – すべてのコピーをローカルマシンに持つため，リポジトリとネットワーク通信ができない環境でもローカルマシンにコミットを残せる

+ バージョン管理システムのモデル – ロックモデル – マージモデル + バージョン管理システムの移り変わり + Git を使ったスムーズな並行開発 + Git を使った開発フロー

+ ソースコードと異なる管理の難しさ – 複数人でDB変更を行うと，SQLの適応漏れや順番の違いなどによって容易にDBの整合性が損なわれる可能性 + 考えつく案 – データベース管理者に変更管理を任せる  作業のボトルネックになってスピードが損なわれる  属人性が高くなる – 共有データベースでスキーマを変更する場合  開発のために変更を加えるとほかの人に影響

+ データベースの変更を管理するツール + ツールの発想 – SQL の適用順とどこまで適用したかを管理 – スキーマ定義編集の衝突を管理 – ロールバックの仕組みを用意 – データのロードもできる + 具体的なツール例 – Migration: Ruby on Rails – south: Django – Migrations Plugin: CakePHP – Evollution – Play Framework

1.sql 2.sql • 適応順をファイル名で管理 • ロールバックのための処理とアノテーション

+ 構築された DB は本当に正しいでしょうか？ + 正しいかどうかを自分で手作業で確認しますか？ + NO：DB 整合性チェクは自動で行えます

+ 設定ファイルもバージョン管理 – すべてがバージョン管理システムにあって，そこにあるファイルだけでアプリケーションの構築から起動まで，いつでもだれでも自動でできるようにしておかないと，高い品質とスピードを維持した開発はできない + 依存関係解決システム – ある程度の規模のアプリケーション開発をするときは，何らかのライブラリを利用 – アプリケーションが管理している依存関係の定義もバージョン管理 – 依存関係解決システム  Apache Ant (Apache Ivy)  Maven  Sbt  Gradle

+ 「管理できるものはすべて VCS で管理すべき」 + 使うなら SVN じゃなくて Git – Git の運用方法に興味ある人は本読んで下さい – Github を試してみてください + 自動化のためのツールを活用 – DB のバージョンごとの管理には，データベースマイグレーションツールがある – 依存関係解決システムで，プロジェクトに必要なライブラリを管理 – サーバ構築やプロビジョニングの話は後ほど

+ プロジェクトの見える化 + タスクの整理，進捗の管理，情報の共有 – タスクの定義：なにをするのか？ – 期限：いつまでにするのか？ – 担当者：だれがするのか？ – ステータス：いまどうなっているのか？ + 情報の一元管理と検索性が重要

+ 代替はできるが，人数が多くなって，タスクが増えると破綻する + メールで管理 – 途中からアサインされた人は過去の情報がわからない – ほかのメールに埋もれる – ステータスがわからない – 担当者がわからない + 共有フォルダで管理 – 複数に編集でファイルが壊れる可能性 – だれかが誤って削除する可能性 – 検索性が低いためドキュメントを探しにくい

タスクタイトルサブタスク報告者と担当者ステータス期限

+ タスクを管理するための基本機能がある – 「なにをしなければいけないのか」というタスクの定義 – 「誰がするのか」という担当者のアサイン – 「いつまでにするのか」という期限の管理 – 「いまどうなっているのか」というステータスの管理 + 一覧性，検索性が高い + 情報の一元管理と共有が可能 – 過去のやりとりやそこから得られた知見，プログラムの仕様 – タスク管理だけでなく，ナレッジデータベースとしての側面も持てる + レポーティングに利用できる – バーンダウンチャートなどのレポーティング機能 + ほかのシステムとの連携が可能であり，拡張性を高める – バージョン管理システムや Continuous Integration システムとの連携を深めることで，問題の発生からコードの修正内容やテスト結果，リリース状況まですべてを関連付けて管理することができる + 追跡可能性が高まる – 例：「昔のバグ修正ってどういう経緯だったけ？」 – 例：チケットIDとバージョン管理の関連付け

対応チケットソースコードの変更差分【チケットID】 FUNC-123 【チケットタイトル】ユーザのお問い合わせフォームの変更【内容】ユーザのお問い合わせフォームのデザインと問い合わせ内容にカテゴリを追加【コミットメッセージ】 FUNC-123 ユーザのお問い合わせフォームを変更した

+ OSS – Trac – Redmine – Bugzilla + 商用 – JIRA  個人のプライベートタスクにも便利  クラウド版は 10 Users $10/month – Backlog – Github + ツール選定のポイント – 拡張性の高さと容易さがどこまで提供されているか – エンジニア以外のステークホルダーも触れるので，業務フローに合わせて柔軟に拡張できるかが重要

+ チームのプロジェクト管理だけでなく，他部署への作業依頼 – 「サーバにこのソフトウェアをインストールしてください」 – 「こことあそこの通信の疎通をしてください」 + カスタマーサポートの管理

+ メールやエクセルでの管理はやめましょう + タスク管理ツールと wiki を使って，タスクと情報共有を一元管理しましょう + チケット駆動開発という方法もあります

+ 各人のソースコード成果物を１箇所に集める + 依存するライブラリなどを解決 + 必要であればコンパイル + データベースの構築と必要なデータのロード + 必要であればミドルウェアの設定や起動 + 単体テストと結合テスト，ユーザ受け入れテストなどを実施

+ インテグレーションを絶え間なく短時間で自動的に実行できる仕組み + メリット – ソースコードの修正をコミットしたすぐに問題ないかどうかを調べることができる + アジャイル開発手法の１つであるエクストリームプログラミング（XP）のプラクティスとして提唱 + 価値のあるソフトウェアを高品質かつ迅速に提供することを目指すアジャイル開発の中でも，最も基本的で重要なプラクティス

要件設計開発ユニットテスト結合テストユーザ受け入れテスト３0 日〜半年時間が経過すればするほど，修正・変更のコストが増す

レビュー開発２週間レビュー開発２週間レビュー開発２週間 • 短い期間で要件自体の修正，要件とのズレを検出し調整できる • アジャイルを実施するためには継続的インテグレーションが必要

+ ウォーターフォール – インテグレーションは開発作業がすべて完了したあとのテストフェースに入って初めて行う – テストフェーズになって，ライブラリの漏れやコンパイルができないなどの問題が発生 – コード量が増えれば増えるほど，修正が困難になる – プロジェクト終盤になってすべてやり直しになるリスクがある + Scrum（アジャイル開発） – スプリントという２週間程度の短いサイクルで設計開発と単体テスト，結合テスト，ユーザ受け入れテストを複数回実施 – スプリントごとに成果物を出し，スプリントレビューというプロセスで成果物をレビュー，フィードバックし，つぎのスプリントに反映するということを繰り返す – 要件の変更への柔軟な対応やズレをできるだけ早く検出して調整する回数を増やしていこうというアプローチ

+ コストメリット – バグの修正コストはバグが生み出された瞬間から時間が経過するごとに増加していく – テストをせずに，昨日生み出されたバグより３ヶ月たったバグを修正するのは困難 – ビルドとテストを自動化して，CI を実施できればコミット後にバグの発生に気づける + 市場の変化のスピード – １つの製品に１年も２年もかけていたら市場が変化してしまい，リリースしたころには市場にマッチしない可能性 – たとえ会計システムのような業務システムでも，急な法改正などで外的環境が変化

+ ソースコード + テストコード + バージョン管理システム – Git + ビルドツール – Maven – Sbt – Gradle + CI ツール – Jenkins  CIツールのデファクトスタンダード – TravisCI  Github のプロジェクトのみ利用可能

+ ソフトウェアのビルドやcronで起動するジョブなどの繰り返しのジョブの実行を監視 – 継続的なソフトウェアプロジェクトのビルドとテスト  ソースコードのデプロイもできる – 外部で起動するジョブの実行監視

+ なんのためにテストを書くのか？ – 機能を担保するため – のちのち修正変更をしやすくするため – 自分を守るため + 単体テストの種類 – TDD (Test Driven Development) – BDD (Behavior Driven Development)

+ テストと開発を平行して実施 public class User { } @RunWith(JUnit4.class) public class UserTest { } ソースコードテストコード

+ 失敗する機能要件のテストを書く public class User { } @RunWith(JUnit4.class) public class UserTest { @Test public void testCreateInstance() { User bob = new User(“Bob”); } } ソースコードテストコード

+ テストをクリアするコードを書く public class User { private String name; public User(String name) { this.name = name; } } @RunWith(JUnit4.class) public class UserTest { @Test public void testCreateInstance() { User bob = new User(“Bob”); } } ソースコードテストコード

+ 失敗する機能要件のテストを書く public class User { private String name; public User(String name) { this.name = name; } } @RunWith(JUnit4.class) public class UserTest { @Test public void testCreateInstance() { User bob = new User(“Bob”); } @Test public void testGetName() { User bob = new User(“Bob”); assertEquals(“Bob”,bob.getName() ); } } ソースコードテストコード

+ テストをクリアするコードを書く public class User { private String name; public User(String name) { this.name = name; } public String getName() { return this.name; } } @RunWith(JUnit4.class) public class UserTest { @Test public void testCreateInstance() { User bob = new User(“Bob”); } @Test public void testGetName() { User bob = new User(“Bob”); assertEquals(“Bob”,bob.getName() ); } } ソースコードテストコード

+ コードの問題点が狭い範囲に絞られやすくなる + プログラムを書くのに前進感がでて楽しい

+ 常にビルド，常にテストを回すことで，加えた修正それ自体が問題ないか，既存の機能を壊していないかをすぐに知れる – 要件定義・開発からテストまどの期間が長くなればなるほど，修正・変更コストが増大 + CIツールを導入することで，ビルドやテストに問題が発生したときに追跡可能 + Jenkins がデファクトスタンダード + TDDは楽しいし，コードの問題点を局所的にできる

+ 「デプロイに関わる作業はすべて自動化すべきである」 – デプロイ：開発したソースコードを利用可能な状態でサーバに配布する一連の行為 + コミットして問題なければ自動的にデプロイ + ポチッと１クリックでだれでも簡単にデプロイ + とにかく，だれでも簡単にデプロイできることが重要！

+ 細かく頻繁にデプロイできればリスクをコントロールしやすくなる – 何ヶ月に１回の大きな変更のデプロイをすると，不具合が起きた時の被害をコントロールするのが難しくなる – こまめに変更をデプロイすることで，不具合の規模感をコントロールできる + フィードバックを早く得られる – 新しく開発した機能をいちはやく試してもらい，そのフィードバックをつぎの開発サイクルに反映 – 短期間のPDCA サイクルを実現 + 組織がスケールする – たとえば 10 個のプロダクトがあり，10 通りのデプロイ方法を手動で延々と行い続けるのは得策ではない – だれでも簡単にデプロイできるようにすることでメンテナンスコストを低くし，新しいことにチャレンジしていける組織になれる – 属人性の排除

+ プロビジョニング – 利用可能なサーバに、適切なOS, ミドルウェア，アプリケーションをロードし、システムを適切に設定したり、サーバ固有の設定（IPアドレスなど）をしたり、といった作業 + プロビジョニングツールチェーン – ブートストラッピング  サーバの OS 設定や仮想マシンによるサーバ立ち上げの自動化ツール – コンフィギュレーション  サーバやミドルウェアの設定の自動化ツール – オーケストレーション  ソースコードのデプロイやリリースに関わるサーバの操作の自動化ツール

+ Vagrant – 仮想マシン作成やその環境設定などを自動化するツール + Chef – 物理、仮想、クラウドといったさまざまな大きさのインフラに対して、サーバやアプリケーションの展開を容易にするための自動化フレームワーク – 自動でミドルウェアをインストールするためのツール + Serverspec – サーバの状態をテストするためのフレームワーク + サーバ構築要件 – CentOS 6.5 – MySQL 5.1, Apache 2.3 – Port は 80 を開ける

Vagrantfile Chef cookbook specfile CentOS6.5 で仮想マシンの作成 Vagrant Chef MySQL 5.1, Apache 2.3 のインストール serverspec 80 番ポート開いてる？ MySQL 5.1 入ってる？ Apache 2.3 入ってる？

ビジネスアイディアビジネスゴール開発環境の構築開発コミットビルドテスト環境構築自動テスト本番環境構築リリースコンフィグレーション継続的インテグレーション継続的デリバリー Chef serverspec Kickstart Vagrant AWS Git Jenkins Chef serverspec Kickstart Vagrant AWS Selenium Chef serverspec Kickstart AWS Capisrano Fablic Chef serverspec デプロイ

+ 「デプロイに関わる作業はすべて自動化すべきである」 – {開発,ビルド}環境の構築 – ビルド – テスト環境の構築 – テスト – リリース – コンフィギュレーション + モダンな開発では環境構築やサーバ構築テストも自動化 – Vagrant + Chef + serverspec

Aさんほかの開発者タスク管理はメールやエクセルテスト担当者本番サーバソースコード用共有フォルダソースコードはフォルダ名を変えることで管理各自の環境はバラバラに構築検証用のステージング環境はない手作業でリリース知識の共有が行われていないバグ報告者

+ タスクの管理は，タスク管理用ツールを活用されている – バグ報告者はタスクのステータスを確認することで問い合わせコストがなくなるなど + ナレッジは wiki にまとまっている – 新しいメンバーも簡単に検索することができて，スムーズにプロジェクトに必要な知識を身につけられる – ひとの時間を奪わない + 検証環境が用意されている – 報告されたバグをすみやかに再現できる + 確認作業，テストがすべて自動化されている + 各自の環境を自動的に整える仕組みがある – 各自の環境が異なっているために起きる問題がない + ソースコードは適切にバージョン管理されている – 過去の履歴を追跡できる – 互いに上書きするリスクを抑えられる + 自動的にリリースする仕組みがある – 間違えたり忘れたり，また属人性を排除するために手作業はなくす

バグ報告者ほかの開発者タスクはタスク管理ツールで管理業務知識は Wiki に一元管理各自の開発環境は自動プロビジョニングで統一 Git による適切なバージョン管理ビルド，テストリリースなどデプロイの自動化ステージング環境（自動構築）継続的インテグレーション継続的デリバリー本番環境リリース

+ 世の中こんなに便利になっているんだ，モダンな開発ってこういう風なんだというのを知ってください – 細かいツールの使い方や運用フローの解説はしません

+ 自動化 + 追跡可能性 + 再現性 + {属人性,暗黙知}の排除 + 人間は間違えかつ忘れる

「チーム開発実践入門」勉強会

by yuishikawa on May 09, 2014

Statistics

Views

Actions

1 Embed 0

Accessibility

Categories

Upload Details

Usage Rights

Report content

「チーム開発実践入門」勉強会 Presentation Transcript