Monthly Archives: 4月 2014

「継続的デリバリー」第13回 (4/25)

Posted on by 0 comment

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

範囲 pp.154-162

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

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

  • 5.2 デプロイメントパイプラインとは何か? (p.154 下から8行目~)
    • p.155 図5-2
      3つ目の流れで「ビルド&ユニットテスト」からフィードバックがないのはなぜ? 単なる書き忘れ?
    • p.155 中程
      「このトレードオフについては…」は何と何のトレードオフ? 上の二つの右向き矢印と下の左向き矢印が示しているもののこと?
    • 5.2.1 基本的なデプロイメントパイプライン
      • p.158 図5-4
        バージョンコントロールにある[環境&アプリ設定]はなぜ二つに分けてある?受け入れステージ用とUAT, キャパシティステージ, 本番用でバージョンコントロールのリポジトリを分ける必要があるのか?
  • 5.3 デプロイメントパイプラインのプラクティス
    • 5.3.1 バイナリをビルドするのは1回限りとせよ
      • p.161 l.4
        「確実にバイナリがバックアップすることに価値はない。」は、
        「確実にバイナリバックアップすることに価値はない。」または
        「確実にバイナリがバックアップされることに価値はない。」の間違い?

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

Posted on by 0 comment

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

範囲 pp.140-154

第1部 基礎

第4章 テスト戦略を実装する

  • 4.3 実際に起こり得る状況と戦略
    • 4.3.3 レガシーシステム
    • 4.3.4 インテグレーションテスト
  • 4.4 プロセス
    • 4.4.1 欠陥バックログを管理する
  • 4.5 まとめ

 

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

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

  • 5.1 導入
  • 5.2 デプロイメントパイプラインとは何か?(p.154、l.22まで)

 

「継続的デリバリー」第11回 (4/18)

Posted on by 0 comment

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

範囲 pp.130-140

第1部 基礎

第4章 テスト戦略を実装する

  • 4.2 テストの種類
    • 4.2.2 受け入れテストを自動化する
    • 4.2.3 開発プロセスをサポートする技術視点のテスト
    • 4.2.4 プロジェクトの評価をするビジネス視点のテスト
    • 4.2.5 プロジェクトを評価する技術視点のテスト
    • 4.2.6 テストダブル
  • 4.3 実際に起こり得る状況と戦略
    • 4.3.1 新規プロジェクト
      • p.137 箇条書き3 INVEST原則の各文字が表している単語は?
        • I – Independent
        • N – Negotiable
        • V – Valuable
        • E – Estimable
        • S – Small
        • T – Testable

        Ref. INVEST in Good Stories, and SMART Tasks

    • 4.3.2 プロジェクトの途中
    • p.139 l.10 中程 脱字
      できだけ多くの → できだけ多くの

「継続的デリバリー」第10回(4/15)

Posted on by 0 comment

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

第1部 基礎

第3章 継続的インテグレーション

  • 3.7 分散したチーム
    • 3.7.3 技術的な問題
    • 3.7.4 代替案
      • p.120 第2段落の最後の方
        バイナリのハッシュはコンパイルし直しても一緒になる?
  • 3.8 分散バージョン管理システム
    • シェルブ(shelve:棚上げする)
      チェックインはまだしたくないけどリポジトリには保存しておきたい、別のタスクに着手する必要がある、といったときにチェックインせずに一時的にリポジトリに保存する機能のようです。
    • 下から8行目 「伝統的なモデルでは、…」
      文に主語がないからわかりづらい。
  • 3.9 まとめ

第4章 テスト戦略を実装する

  • 4.1 導入
  • 4.2 テストの種類
    • 4.2.1 開発プロセスをサポートするビジネス視点のテスト

「継続的デリバリー」第9回(4/11)

Posted on by 0 comment

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

範囲 pp.107-118

第1部 基礎

第3章 継続的インテグレーション

  • 3.5 基本的なプラクティス
    • 3.5.1 ビルドが壊れているときにはチェックインするな
    • 3.5.2 コミットする前に、常にローカルでコミットテストを実行せよあるいは代わりにCIサーバーにやってもらえ
    • 3.5.3 次の作業を始める前に、コミットテストが通るまで待て
    • 3.5.4 ビルドが壊れているのに、家に帰ってはならない
    • 3.5.5 常に以前のリビジョンに戻す準備をしておくこと
    • 3.5.6 リバートする前にタイムボックスを切って修正する
    • 3.5.7 失敗したテストをコメントアウトするな
    • 3.5.8 自分が変更してビルドが壊れたら、すべてに対して責任をとれ
    • 3.5.9 テスト駆動開発
  • 3.6 やったほうがいいプラクティス
    • 3.6.1 エクストリームプログラミング(XP)の開発プラクティス
    • 3.6.2 アーキテクチャ上の違反事項があった場合にビルドを失敗させる
    • 3.6.3 テストが遅い場合にビルドを失敗させる
    • 3.6.4 警告やコードスタイルの違反があったときにビルドを失敗させる
  • 3.7 分散したチーム
    • 3.7.1 プロセスに与えるインパクト
    • 3.7.2 中央集権的継続的インテグレーション

「継続的デリバリー」第8回 (4/8)

Posted on by 0 comment

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

範囲 pp.96-107

第1部 基礎

第3章 継続的インテグレーション

  • 3.2 継続的インテグレーションを実現する
    • 3.2.1 始める前に必要なもの
      • p.97 「1. バージョン管理」の下から2行目
        なぜここだけ「リビジョン管理システム」と言っているのだろう?
      • p.97 「2.自動ビルド」箇条書き二つ目
        ここで言っている「IDEが作り出すビルドプロセス」とはIDEで行うビルドを言っているのであって、例えばJavaでEclipseを使用してAntのbuild.xmlを生成して使用することは言っていないと思う。この場合はコードベースと同じように扱うことができるし、自動実行でも使用できる。
    • 3.2.2 基本的な継続的インテグレーションシステム
      • p. 98 3.2.2 l.7
        この本ではHudsonって書いてあるがJenkinsになったのは何時?→ 2011年2月。この本の原書は2010年8月。
  • 3.3 継続的インテグレーションの前提条件
    • 3.3.1 定期的にチェックインせよ
      • p.100 最後の方
        ここで推奨されていないブランチは、タスクブランチやワークブランチだろうか。リリースブランチはどうするのだろう。14章に詳しくでてくるか。
    • 3.3.2 包括的な自動テストスイートを作成せよ
    • 3.3.3 ビルドプロセスとテストプロセスを短く保て
      • p. 102 l.5
        NUnitのNは何?→ .Net言語用でした。
    • 3.3.4 開発ワークスペースを管理する
  • 3.4 継続的インテグレーションソフトウェアを使用する
    • 3.4.1 基本的な操作
      • p.105 図3-1
        川口耕介さんは、Hudsonの開発者。
    • 3.4.2 オプション機能
      • p.104 最下行
        Nabaztagとは? → ウサギの形状をしたネットワークロボットだそうです(Ref. http://ja.wikipedia.org/wiki/Nabaztag)。
        (Googleで検索すると画像もいっぱいあります。)

「継続的デリバリー」第7回(4/4)

Posted on by 0 comment

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

範囲 pp.85-96

第2章 構成管理

  • 2.4 ソフトウェア設定を管理する
    • 2.4.3 アプリケーションの設定を管理する(システム設定をテストするがら)
      「pingを打つことはできるだろう」は外部サービスがpingを無視しない前提ですね。
    • 2.4.4 アプリケーションをまたいで設定を管理する
      「深淵」は「シンエン」と読む。
    • 2.4.5 アプリケーション構成管理の原則
      具体例があると分かりやすく、覚えやすい。
  • 2.5 環境を管理する
    • 2.5.1 環境管理のためのツール
    • 2.5.2 変更プロセスを管理する
  • 2.6 まとめ

第3章 継続的インテグレーション

  • 3.1導入

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

Posted on by 1 comment

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

範囲 pp.75-85

第2章 構成管理

  • 2.2 バージョン管理を使う
    • 2.2.3 意味のあるコミットメッセージを使え
      何をしていたかではなくどこを変更したかを書いてしまうことがある。 →コメント参照
      1人で開発しているとメッセージを省略してしまうことがある。これからは省略しないように頑張ります。
  • 2.3 依存関係の管理
    • 2.3.1 外部ライブラリを管理する
    • 2.3.2 コンポーネントを管理する
  • 2.4 ソフトウェア設定を管理する
    • 2.4.1 設定と柔軟性
      eclipseでJavaなど使って開発しているとIDEの機能で容易にソースコードを追えるが、設定にするとその機能が使えなくなる。
    • 2.4.2 設定の種類
    • 2.4.3 アプリケーションの設定を管理する(システム設定をテストするの前まで)
      パスワードに関連して脱線。SMBCでは認証用のパスワードカードというものがある。財布に入れるにはこのカードは厚過ぎる(3.3mm)と思う。
      UATとは、発注元ユーザ検証テスト(User Acceptance Test)。