【大阪】継続的デリバリー読書会(12回目)に参加してきました!

  • 2013.03.26 Tuesday
  • 04:50
  
それでは、読書会での速記メモ .〆(・ω・` )カキカキ

■10.5「緊急修正」
・ロールバックも緊急修正の一つの手段
・応急処置でパッチを充てるだけが緊急修正ではない

■10.6「継続的デプロイメント」
・数をこなすしかない!

■10.7.1「実際にデブロイメントを行う人たちを、デブロイメントプロセスの策定に参加せよ」
・理由:誰でもデブロイ出来るため。
・誰でも理解しているということが重要。

■10.7.2「デプロイメント作業を記録せよ」
・デバック用・緊急用の2つの意味がある?

■10.7.3「古いファイルは削除せず、移動せよ」
・成果物管理だけでは予測できない不測の事態に備えるため
・2世代ぐらいとる?
・diffのdiffを取るのも有効

■10.7.6「最初のデプロイメントにはウォームアップ期間を持たせよ」
・単に温めの意味?

■10.7.7「失敗は早めに」
・失敗していたら、動作させないため

■12.1「導入」
・DBの成長は2種類ある
 →顧客操作による成長
 →システム変更による成長

・DBのライフサイクルは長い

■12.4.1「データを失わずにロールバックする」
・1世代のみ?
・リストア&ロールフィードバックという方法もある →でも大変


■まとめ
今回で読書会として「継続的デリバリー」読み合わせは終了となりました。
自分でも再度読み直して、まとめてみたいと思います。


【大阪】継続的デリバリー読書会(11回目)に参加してきました

  • 2013.03.12 Tuesday
  • 06:23
 
それでは、読書会での速記メモ .〆(・ω・` )カキカキ

■9.6 キャパシティテストを自動化する
・受け入れテストを書き換えるとあるが、コピー?クローン?
 →テストに変更が発生すると、受け入れテスト、キャパシティテストの2ヶ所書き換え必要?
 →それとも実行回数などをパラメーター化しておき、受け入れテストを使って実行回数を増やすごとでキャパシティテストとするのか?
・通常時の高負荷処理テストと、高負荷時の通常処理テストは意味が違う

■9.6.1 ユーザインターフェイス経由のキャパシティテスト
・薄っぺらくて軽量なUIは、UI経由でのキャパシティテストは難しいとあるが、この場合の難しいとは何に対してなのか?
 →クライアントを対象にしたUIのテストで考えると、薄すぎて相当数のテスト端末が必要になるので、用意が大変とういう意味の難しいなのであろうか?

■9.7 キャパシティテストをデブロイメントパイプラインに追加する
・キャパシティテストにも、ガードテストを用意するのはクラウドテスト環境だと価値が高い
 →クラウドでは処理時間等によっても課金が発生するから。

余談、話の中で「8.4.2  ウィンドウドライバパターン:テストとGUIを疎結合にする」について議論がありました。
seleniumなどでページテストするときに、モデルとテスト対象ページの間差に、ページオブジェクトなどを用意し、テスト対象ページの変更対応をページオブジェクトで吸収しようとする考えは、ユースケースと一致しないことになる。
つまり、ユースケースでテストという観点から考えると、WEB経由ではなく、API直接たたくテストが望ましいということになる。

■10.2 リリース戦略を作成する
・ステークホルダーの参加
 →出来たらいいね。
・10.2に挙げられている項目は、プロジェクト開始時にこれだけ考えとけという指標
 →なかなか出来ないよね。

■10.2.1 リリース計画
・最初のリリースのリスクとは何か?
 →何もないところへのリリースならばリスク低いのでは?
 →システム差し替えでの最初のリリースならば確かにリスクあるよね。
 →顧客側のリスクではなく、作り手側のみのリスクを示している?
 →もしデブロイを全自動化するのなら、デブロイで失敗する可能背があるのは、この最初のリリース時のみになる?

■10.3 アプリケーションをデブロイする
・テスト環境へ最初にデブロイするとあるが、最初にデブロイするのは開発環境なのでは?

■10.3.1 最初のデプロイメント
・一番最初は受け入れテストはないよね

■10.3.3 設定を反映させる
・リリースするバイナリという文章が示す「バイナリ」の範囲が広すぎる

■10.4.4 カナリアリリース
・カナリアリリースではDBは一つですよね。


【大阪】継続的デリバリー読書会(9回目)に参加してきました

  • 2013.02.13 Wednesday
  • 04:03
【大阪】継続的デリバリー読書会(9回目)に参加してきました。
それでは、読書会での速記メモ .〆(・ω・` )カキカキ

■全般
・本日の範囲は「第8章 自動受け入れテスト」の後半が範囲でした。

・テストダブルのメリット
 →テスト並列実行が可能
 →他テストへ影響を与えない。


■8.4.2
・ウィンドウドライバパターンの価値って何?
 →抽象レイヤーでラップしているので、GUIに対するテストに対して脆くならない


■8.5.1
・この節での自動受け入れテストは、一般的な受け入れテスト全般の一部である
 (つまりこの節においては、受け入れテスト≒自動受け入れテストと読み替えたほうがよい?)
 (p228の受け入れテストステージがその範囲?)

・プロダクションデータのダンプを利用したい疑惑の問題点とは?
 →テストの最小必要単位などが見えなくなってしまう。

・APIを叩こう
 →現実的には、きれいにGUI層と分離できてるAPIなんて用意できないよねw
 →設計大事。
 →でも、Railsなら出来る!

・ロールバック方法がエンドツーエンドでない理由
 →やはり、commitしていないから?
 →GUIテストの場合、ロールバックは行わない。

・テスト開始状態をアサーションでチェック?
 →これってTDDじゃ御法度では・・・
 →つまり、ユニットテストと受け入れテストでプラクティスが異なることを理解しておく必要がある。
 →TDDはプログラマーの為、受け入れテストは客の為。



■8.5.2
・特別な決め打ちデータって?
 →デバックモードのようなイメージ?

・受け入れテスト(外部システムとの連携ありパターン)の担当範囲イメージは?
下記2図のイメージ

ちなみに下記図はユニットテストのイメージ図



■8.5.4
・毎回テスト実行しても良いパターン
 (外部システムへの負荷を気にしなくてもよい)

・1日に1度、週に1度など定期毎に実行するパターン
 (外部システムへの負荷を気にする必要がある)



継続的デリバリー読書会(6回目)に参加してきました

  • 2012.12.18 Tuesday
  • 04:53
 本日は、6章「ビルド・デプロイメントスクリプト」がメインとなりました。
それでは、読書会での速記メモ .〆(・ω・` )カキカキ

■全般
・ドキュメントとソースや手順書の同期って難しいよね。
 →その為、スクリプトを通じてのブルとに限定するという話に繋がる。
・ライブラリ管理でライフサイクルが異なる場合は、1つにまとめなくて、サイクル毎に分けて管理するのも有りですね。

■6.1~6.2.7
・Gradle使おうぜ!(by @irofさん)

■6.3.3 全ての環境にデプロイするのに、同じスクリプトを使え
・超強調!

■6.4.1 プロジェクトのレイアウト
・テストレイアウトは注意必要。

■6.4.4 ビルとの成果物を管理する
・機能単位で管理すると、パッケージ間で機能がまたがると管理が大変。
・そもそもドメイン駆動開発が出来ていない??

■6.4.5 ライブラリを管理する
・依存関係グラフ
 →双方向はダメ
 →ダイヤモンド継承などを管理
 →多数のライブラリを見るのはOKだけど、整理が必要。

■6.5 デプロイメントスクリプト
・スモークテストを網羅する?
 →それって、燃えすぎ。あくまでスモークテストは軽くすべきでは?


■6.6.3 バイナリからバージョン管理へのトレーサビリティを組み込め
・Jenkins使う

■6.6.5 テストが失敗してもビルドは続けよ
・ユニットテストが失敗したのなら、デプロイストップで良いのでは?

■6.6.6 統合スモークテストでアプリケーションに制約をかけよ
・制約を掛けるとは、デプロイを止めるということなのか?

【大阪】継続的デリバリー読書会(5回目)に参加してきました

  • 2012.12.04 Tuesday
  • 09:11
【大阪】継続的デリバリー読書会(5回目)に参加してきました。
その時の速記メモです。

■5.1
・開発規模が大きいチームだと、本番移行チームというのが出来るよね。
・その移行チーム≒リリースチームのイメージ
・リリース間隔が広がると、リリース作業が複雑になるよね。
・リリーステスト≒リハーサルとしておこなっている所もある

■5.3
・単体テストでも、受け入れテスト、本番デブロイなど全て、同じビルド物を使うべし!

■5.3.2
・開発用PC、テスト用PC、デモ用、本番・・・これらがあらゆる環境という意味らしい
・デブロイ回数が増えると、デブロイのテストになりデブロイが洗礼されていくよね

■5.3.3
・スモークテスト…どこまでやるかが問題。テストが大きくなるとやらなくなる危険がある

■5.8
・CIもCIしないとね

■5.9
・あくまでものさしとみなさないと部分適応が発生する。
 例:特定個所のテストが薄い→
    開発者に単体テスト増加を依頼→
     開発者は面倒くさく意味のないテストを用意→
      テスト数は増えたが効果なし

■まとめ
今回の個所は実戦していない箇所なので、ピンとこなかった所がおおかったのですが、
参加者の意見を聞いてイメージを掴む事ができました。
デブロイ自動化なんて、業務が使わない限り、進歩しづらいですもんね。
次回6章からは実際のツールの話しになるので、期待です。


 


継続的デリバリー読書会(4回目)に参加してきました

  • 2012.11.19 Monday
  • 23:53
 本日、継続的デリバリー読書会(4回目)に参加してきました。
今回は、「第4章 テスト戦略を実装する」ということで非常に楽しみな回となりました。

以下は読書会での速記メモ .〆(・ω・` )カキカキ

■そもそもテスト戦略って?
・優先度と考えてもいいのでは?
・ドメイン層は多くのテストを行い、プレゼンテーション層は少しにするとか。

■4.2
・スクラムを回すより、質を高めよう。
・つまり、Doneの定義を厳密化していくこと

■4.2.1
・ここでの機能って、ストーリ、つまりユースケーステストの事?
・ウォーターフォールにこの概念ってあるの?
・終わりっていうのが重要

■4.2.2
・テスターって人を示すものではなく、役割やロールだよね。
・正常系が一番ROIが高い。
・代替パスはフローにより変更激しいので、手動テストが良いかも

■4.2.3
・デブロイテスト・・・本番環境での環境設定テストのこと?

■4.2.4
・バグなのか仕様ミス・要求ミスなのかはどうでも良くて、価値があるのならやるべし!
・その際、作業に対する金額はバグでも仕様ミスでも同額。
・VPN接続で、ユーザに常にデブロイしたアプリ画面を見てもらっていた

■4.2.3
・探索的テスト・・・テスト手法の知識は必要
・バグ見つける、神の手をもった人いるよね

■4.3
・積みっぱなしになっているバグリストは、優先度的にやらなくてもよい
・定期的にバグリストから古いリストは削除しちゃう!


■当日の感想
テストを継続的にする意味として、ユーザに価値を正しく届けられているのか確認する意味もあるのかなーと漠然ながら思いました。





PR

calendar

S M T W T F S
     12
3456789
10111213141516
17181920212223
24252627282930
31      
<< December 2017 >>

selected entries

categories

archives

recommend

カンバン仕事術
カンバン仕事術 (JUGEMレビュー »)
Marcus Hammarberg,Joakim Sundén

recommend

recommend

profile

search this site.

others

mobile

qrcode

powered

無料ブログ作成サービス JUGEM