Monthly Archives: 5月 2014

「継続的デリバリー」第20回 (5/30)

Posted on by 0 comment

参加者 沼田(読み手)、今井、青木(記)

範囲 pp.231-244

第2部 デプロイメント パイプライン

第7章 コミットステージ

  • 7.4 コミットテストスイートの原則とプラクティス
    • 7.4.2 DIを使用せよ
      DIはよく耳しますが、IoCはあまり聞いたことがありませんでした。
    • 7.4.3 データベースを避けよ
    • 7.4.4 ユニットテストでの非同期処理を避けよ
    • 7.4.5 テストダブルを利用する
      誤りがいくつかあります。
      p.234 「まずEngine.accelerateを呼び出した上で、Engine.startが呼び出されることを期待する」は呼び出し順序が逆です。
      p.235 class Carでコンストラクタで「this.Engine = engine;」とありますが、正しくは「this.engine = engine;」です。
      Interface Engineで定義されているメソッドに戻り値の型がありません。
      p.236 class CarTestCaseで「Mock mockEngine = mock(Engine);」とありますが、 「Mock mockEngine = mock(Engine.class);」の誤りだと思います。
    • 7.4.6 テスト内の状態を最低限に抑える
    • 7.4.7 時間の概念を偽装する
    • 7.4.8 しらみつぶし
  • 7.5 まとめ

第8章 自動受け入れテスト

  • 8.1 導入
  • 8.2 なぜ自動受け入れテストが欠かせないのか?

「継続的デリバリー」第19回 (5/27)

Posted on by 0 comment

参加者 青木(読み手)、沼田、今井(記)

範囲 pp.221-231

第2部 デプロイメント パイプライン

第7章 コミットステージ

  • 7.1 導入
    • p.222 図7-1下の箇条書き4つめ
      ここに書かれている、“…後のステージで使われることになる成果物(…)をすべて生成する。”に対応するものが図7-1にない。

      • そもそも成果物として書かれている、“データベース移行スクリプトやテストデータ”は、自動で生成できるようなものなのか?
  • 7.2 コミットステージの原則とプラクティス
    • 7.2.1 役に立つフィードバックを素早く提供せよ
    • 7.2.2 どういうときにコミットステージを止めるべきか?
    • 7.2.3 コミットステージを丁寧に整備せよ
    • 7.2.4 開発者に所有権を与えよ
    • 7.2.5 きわめて大規模なチームにはビルドマスターを置け
  • 7.3 コミットステージの結果
    • 7.3.1 成果物リポジトリ
  • 7.4 コミットテストスイートの原則とプラクティス
    • 7.4.1 ユーザーインターフェイスを避けよ

「継続的デリバリー」第18回(5/23)

Posted on by 0 comment

参加者 今井(読み手)、沼田(記)
範囲 pp.208 – 219

第2部 デプロイメント パイプライン

第6章 ビルド・デプロイメントスクリプト

  • 6.4 JVMを対象としたアプリケーションのためのプロジェクト構造
    • 6.4.2 ソースコードを管理する
    • 6.4.3 テストを管理する
    • 6.4.4 ビルドの成果物を管理する
      • targetディレクトリのレイアウト
        [project-name]と同じ階層にCompiled classes、Compiled test classes、Test reportsがあるけど、成果物ではなくて、それぞれclasses、test-classes、surefire-reportsに書かれていたコメントの消し忘れ?
    • 6.4.5 ライブラリを管理する
  • 6.5 デプロイメントスクリプト
    • 6.5.1 デプロイレイヤとテストレイヤ
    • 6.5.2 環境設定をテストする
  • 6.6 コツと裏技
    • 6.6.1 常に相対パスを使え
    • 6.6.2 手作業を根絶せよ
    • 6.6.3 バイナリからバージョン管理へのトレーサビリティを組み込め
    • 6.6.4 ビルド時にバイナリをバージョン管理にチェックインするな
    • 6.6.5 テストが失敗してもビルドは続けよ
      • makeの場合、-kまたは–keep-goingを指定するとエラーが起きても可能な限り実行を継続してくれる。
    • 6.6.6 統合スモークテストでアプリケーションに制約をかけよ
    • 6.6.7 .NETのコツと裏技
  • 6.7 まとめ

「継続的デリバリー」第17回 (5/20)

Posted on by 0 comment

参加者 沼田(読み手)、今井、青木(記)

範囲 pp.197-207

第2部 デプロイメント パイプライン

第6章 ビルド・デプロイメントスクリプト

  • 6.2 ビルドツールの概要
    • 6.2.3 NAntとMSBuild
    • 6.2.4 Maven
    • 6.2.5 Rake
    • 6.2.6 Builder
    • 6.2.7 Psake
  • 6.3 ビルドスクリプトとデプロイメントスクリプトの原則とプラクティス
    • 6.3.1 デプロイメントパイプラインのステージそれぞれに対してスクリプトを書け
    • 6.3.2 アプリケーションをデプロイするのに適切なテクノロジーを使え
    • 6.3.3 すべての環境にデプロイするのに、同じスクリプトを使え
    • 6.3.4 OSのパッケージングツールを使え
      CPANについて、「シーパン」と読む人も「クパン」と読む人もいるようであるが、Webページを検索すると「シーパン」という読み方が優勢であるように思う。
    • 6.3.5 デプロイメントプロセスが冪等であることを保証せよ
    • 6.3.6 デプロイメントシステムをインクリメンタルに進化させよ
  • 6.4 JVMを対象としたアプリケーションのためのプロジェクト構造
    • 6.4.1 プロジェクトのレイアウト

「継続的デリバリー」第16回 (5/16)

Posted on by 0 comment

参加者 青木(読み手)、沼田、今井(記)

範囲 pp.186-197

第2部 デプロイメント パイプライン

第5章 デプロイメントパイプラインの解剖学

  • 5.9 メトリクス
  • 5.10 まとめ

第6章 ビルド・デプロイメントスクリプト

  • 6.1 導入
  • 6.2 ビルドツールの概要
  • 6.2.1 Make
  • 6.2.2 Ant

 

「継続的デリバリー」第15回(5/13)

Posted on by 0 comment

参加者 今井(読み手)、青木、沼田(記)
範囲 pp.173 – 185

第2部 デプロイメント パイプライン

第5章 デプロイメントパイプラインの解剖学

  • 5.6 後に続くテストステージ
    • Go
    • 図5-7
      選んだ環境にデプロイするためのボタンがない?デプロイを押すと環境が選べる?
    • 5.6.1 手動テスト
    • 5.6.2 非機能のテスト
  • 5.7 リリースに備える
    • 正式なデータが入ってしまうと戻すのは大変
      →正式なデータが入るのはリリースが成功して動くのが確認できたあとだからバックアウトはしないのだろう
    • 5.7.1 デプロイメントとリリースを自動化する
    • 5.7.2 変更をバックアウトする
    • 5.7.3 成功を積み重ねる
  • 5.8 デプロイメントパイプラインを実装する
    • 5.8.1 バリューストリームをモデリングし、動くスケルトンを作成する
      • Sahi
        ブラウザベースのWebアプリ向けのテスト自動化ツール
    • 5.8.2 ビルドとデプロイメントプロセスを自動化する
    • 5.8.3 ユニットテストとコード解析を自動化する
    • 5.8.4 受入テストを自動化する
      • Vnc2swf
        SWFフォーマットで画面を録画するツール
    • 5.8.5 パイプラインを進化させる

「継続的デリバリー」第14回 (5/9)

Posted on by 0 comment

参加者 沼田(読み手)、今井、青木(記)

範囲 pp.162-173

第2部 デプロイメント パイプライン

第5章 デプロイメントパイプラインの解剖学

  • 5.3 デプロイメントパイプラインのプラクティス
    • 5.3.2 あらゆる環境に対して同じやり方でデプロイせよ
    • 5.3.3 デプロイメントをスモークテストせよ
    • 5.3.4 本番のコピーにデプロイせよ
    • 5.3.5 各変更は直ちにパイプライン全体を通り抜けなければならない
      図5-6の点線矢印は、ビルドとユニットテストや自動受け入れテストが完了したら新しい変更があるかどうかチェックして、変更があった場合の流れですね。
    • 5.3.6 パイプラインのどの部分であっても、失敗したらラインを止めよ
  • 5.4 コミットステージ
    • 5.4.1 コミットステージのベストプラクティス
  • 5.5 自動受け入れテストという関門
    p.171 下から2行目「受け入れ基準をすべて満たしていないリリース候補がユーザーにリリースされてしまうことがなくなる」という表現では、一部基準を満たしていないリリース候補はリリースされてしまうことがあるように読めるので、「受け入れ基準を満たしていないリリース候補がユーザーにリリースされてしまうことがなくなる」で良いように思います。

    • 5.5.1 自動受け入れテストのベストプラクティス