Monthly Archives: 6月 2014

「継続的デリバリー」第28回(6/27)

Posted on by 0 comment

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

第10章 アプリケーションをデプロイ・リリースする

  • 10.3 アプリケーションをデプロイする
    • 10.3.3 設定を反映させる
      • Nagios
        Nagiosはオープンソースのコンピュータシステムおよびネットワークの監視のためのアプリケーションソフトウェアである(ウィキペディアより)
    • 10.3.4 オーケストレーション
    • 10.3.5 ステージング環境へのデプロイメント
  • 10.4 デプロイメントのロールバック、そしてゼロダウンタイム・リリース
    • 10.4.1 直近の正常動作するバージョンの再デプロイメントによるロールバック
    • 10.4.2 ゼロダウンタイム・リリース
    • 10.4.3 ブルーグリーン・デプロイメント
      • DBはどうする?と思っていたらp320に記載がありました。
    • 10.4.4 カナリアリリース
  • 10.5 緊急修正
  • 10.6 継続的デプロイメント

「継続的デリバリー」第27回(6/24)

Posted on by 0 comment

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

範囲 pp.302-315

第9章 非機能要件をテストする

  • 9.7 キャパシティテストをデプロイメントパイプラインに追加する
  • 9.8 キャパシティテストシステムのもうひとつの利点
  • 9.9 まとめ

第10章 アプリケーションをデプロイ・リリースする

「継続的デリバリー」第26回(6/20)

Posted on by 0 comment

参加者 青木(読み手)、沼田(記)
範囲 pp.291 – 301

第9章 非機能要件をテストする

  • 9.5 キャパシティテスト環境
    • p.291 囲み「iPodクラスター上でのキャパシティテスト」
      iPodクラスタとは?どうやって作るのだろう?
    • p.293 図9-1
      • サーバーファーム
      • この図の書き方だと、Webサーバー×2台、アプリケーションサーバー×4台、データベースサーバー×2台の構成が2つあるように見える
  • 9.6 キャパシティテストを自動化する
    • 9.6.1 ユーザーインターフェイス経由のキャパシティテスト
    • 9.6.2 サービスや公開APIに対するインタラクションを記録する
    • 9.6.3 記録したインタラクションテンプレートを使う
    • 9.6.4 キャパシティテスト用スタブを使ったテスト作り

「継続的デリバリー」第25回 (6/17)

Posted on by 0 comment

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

範囲 pp.281-291

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

第9章 非機能要件をテストする

  • 9.1 導入
  • 9.2 非機能要件を管理する
    • 9.2.1 非機能要件を分析する
      p.283 下から9行目 誤植:「監査人が見えるべきのもは」→「監査人が見えるべきものは」
  • 9.3 キャパシティを確保するためのプログラミング
    O(1)はデータ量に関係なく一定の時間が掛かる
    O(n)はデータ量に比例して掛かる時間も増加する
  • 9.4 キャパシティを計測する
    • 9.4.1 キャパシティテストの成功・失敗の判断基準は?

「継続的デリバリー」第24回 (6/13)

Posted on by 0 comment

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

範囲 pp.271-280

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

第8章 自動受入テスト

  • 8.6 受け入れテストステージ
    • 8.6.1 受け入れテストをグリーンに保つ (p.271 囲み~)
      • p.272 下から3行目 ラバーランプとは?
        LAVA LAMP(ラバランプ)
    • 8.6.2 デプロイメントテスト
  • 8.7 受け入れテストのパフォーマンス
    • 8.7.1 共通のタスクはリファクタリングせよ
    • 8.7.2 高価なリソースは共有せよ
    • 8.7.3 並列テスト
    • 8.7.4 コンピュートグリッドを用いる
      • p.279 図8-5
        この図は、右上のSeleniumグリッドが受け入れテストスイートを読み取り、複数のSelenium Remotingに指示を出し、複数のWebブラウザからのリクエストをセキュアWebサーバで受けて、テスト対象システムをテストするという構成を表している。
  • 8.8 まとめ
    • p.280 中ほど
      退屈な手作業リグレッションテストを繰り返しているより、自動テストを作るほうが創造的で面白いというのもあるのだろうなぁ。

「継続的デリバリー」第23回 (6/10)

Posted on by 0 comment

参加者 今井(読み手)、青木(記)
範囲 pp.260 – 271

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

第8章 自動受入テスト

  • 8.5 受け入れテイストを実装する
    • 8.5.1 受入テストにおける状態 (p.260 下から2行目から)
    • 8.5.2 プロセス境界・カプセル化・テスト
    • 8.5.3 非同期とタイムアウトを管理する
      p.263 フィクスチャとは、テストを開始する前に行う事前設定のこと。
      pp.264-265 細かいことですが、ConfirmEmailWasReceived()のなかのFail()への引数が和訳してあったり、なかったりしています。
    • 8.5.4 テストダブルを利用する
  • 8.6 受け入れテストステージ
    • 8.6.1 受け入れテストをグリーンに保つ(p.271「 受け入れテストは誰の所有物か?」の前まで)

「継続的デリバリー」第22回 (6/6)

Posted on by 0 comment

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

範囲 pp.253-260

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

第8章 自動受入テスト

  • 8.4 アプリケーションドライバレイヤ
    • p.254 中程のソースコード
      • 継承しているDSLTestCaseはJUnitのクラス?
        → 違う。持ってきたプロジェクトで使われているクラスの名前をかえたのではないか?
      • adminAPIやtradingUIの生成は、たぶんこのクラス(または更に上位のクラス)の@Before(setup())で行っているのだろう。
    • p.255 中程の箇条書き
      • 下二つのsecurityQuestion1, securityAnswer1の説明のデフォルトが日本語に訳されているが、passwordなどのデフォルト文字列同様、他の説明とあわせるのであれば英語のままの方がわかりやすい。
      • これらのデフォルト値はどこで設定される?
        → だぶんadminAPIのクラスだろう。adminAPIは省略なしのインタフェースも持っているのだろうか?
  • 8.4.1 受け入れ基準の表現方法
    • p.256 この節の下から5行目のフィーチャーやシナリオ
      “Placing an order”と”User order should debit account correctly”は、p.251の「注文を受けつける」や「ユーザーの注文を口座から正しく引き落とさなければならない」の事。p.251も日本語に訳さないほうがわかりやすかったかも。
  • 8.4.2 ウィンドウドライバパターン:テストとGUIを祖結合にする
    • p.258 下方ソースコード
      昔、フォームのテストか何かでこのようなテストケースを書いてテストしたことがある。
    • p.259 上方ソースコード
      • 最後のassertEquals()の引数はなぜ(String, BigDecimal)にしてあるのだろう? 第2引数が自動でStringに変換されるにしてもわかりにくい。
        → BigDecimalを少し調べてみました。equals()が値が同じだけでは(スケールも同じでないと)trueを返さないので、BigDecimalオブジェクトどうしの比較ではまずいことがありそう。toString()では指数表現になることがあるのでtoPlainString()が良いかも。
      • AccountPanelDriverの実装では、p.258のコードのように書いているのだろうなぁ。
      • AccountPanelDriverのメソッドが呼ばれると、「画面のどこにどの値を入れてどのボタンを押せ」のような指示が表示されて、それにあわせて人間がブラウザを操作するようなウィンドウドライバもできそう。自動化にはならないけど。
  • 8.5 受け入れテイストを実装する
    • 8.5.1 受入テストにおける状態 (p.260 下から3行目まで)

「継続的デリバリー」第21回(6/3)

Posted on by 0 comment

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

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

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

  • 8.2 なぜ自動受け入れテストが欠かせないのか?
    • 8.2.1 保守しやすい受入テストスイートの作り方
    • 8.2.2 GUIを叩いてテストする
      • ここではどこまでをUIと言っているのだろう?
  • 8.3 受入テストを作成する
    • 8.3.1 アナリストとテスターの役割
    • 8.3.2 イテレーティブなプロジェクトにおける分析
    • 8.3.3 実行可能な仕様としての受け入れ基準
      • p251上部の受け入れ基準がfeatures/placing_an_order.feature(読み直したら本文に書いてありました)
      • 日本語の場合は表記の揺れがあるから難しそう
      • 受け入れ基準とテスト実装で異なる点がある。
        • 「もし」の4つ目の記述
        • 「ならば」の句点
      • ドメインの言語だけを使うのが重要なのだろう