自動テスト、自動受入テストについても…
継続デリバリ
継続デリバリとは、自動化してビジネスの必要なタイミングでプロダクトを出荷することである。
製品がデプロイ可能かどうか判断できなければもちろん製品は出荷できない
継続デリバリの重要な点は手動でのテストには時間がかかること。
手動テストは手軽にできるが効率のうえで難がある
But Continuous Delivery is impossible witout Continuous Quality
How dou you deliver?
レベルごとにビジネスゴールが存在する
Gools
Capalibities
Features
Stories
Examples
Acceptance Criteria
書かれている情報も重要だが口述される情報も重要である
we are going to build on online classifieds websites
you define goals to archive your vision
goals that will deliver business value
- 何を実現しようとしているのかを定義
- ビジネスゴールとして何を達成実装していくのかを定義
- ビジネスに貢献するために何が必要なのか分析する
製品がビジネスにvalueを提供しないこともありうる
Features help deliver these goals.
Increasing revenue.
Vision BusinessGoals
コードを書くうえで、なんのためにそのコードが必要なのか知っていなければならない
searching by category
searching by keyword and category
searching by keyword and location
filter ads by price
そのコードを実現するストーリーを知っておく必要がある
ユーザーストーリーに従ったテストシナリオを書くことになる
それを通すコードを書けば自然とユーザーのストーリーを
実現するプロダクトができあがることになる
thucydidesを使う
シナリオを実現し、それによりビジネスゴールを設定する
そしてそのシナリオを実装するまでの過程を(コーディングではなくユニットテストから
受け入れテストまで)自動化することが重要
Jenkinsをいかに活用するか
もちろんコンパイルやテスト、品質管理、リリース候補の選定、レポートやドキュメントの
生成などをやっている
ローアルのマシンで受け入れテストはやりつづけたくない
顧客によっては受け入れテストをjarファイルにパッケージしたりしている
jarファイルをダウンロードして実行すればレポートが自動生成される
なので出荷可能なクオリティに到達していることに自信がもてる
こういった要素が継続デリバリを構成する
継続ビルドは特定のバージョンのソフトを取り出し、テスト、
受け入れ検査をし、そしてプロダクション環境へデプロイする。
企業・組織によっては継続デプロイ(デプロイまで自動化)
しているところもあるが、エンタープライズの環境では
継続デリバリ(デプロイ手前)まで自動化するのが望ましい。
build pipeline
- build and fast tests
- slower testsp
- acceptance tests
- code quality metrics
- release candidate
- deploy to test
- deploy to UAT
- deploy to Production
テストにはビルドして早くできるテストと、やや遅いテストがある
早いテストのセットを定義しておけば、フィードバックを早く得ることが
出来る
早いテストも遅いテストもそれぞれ(Jenkinsのジョブ)として動かす。
そのあと、受け入れテストを実行し、コードのメトリクスを算出する。
これらが通ると、リリース可能なバイナリのセットが出来あがり。
リリース可能なバイナリをできる限り早く作り上げることが重要である。
受け入れテストはその前段階のテストと同じように見えるが…
リリース候補が出来あがれば、ステージング環境にデプロイする
emailアプリケーションでの通知
色々な人に色々なトリガでemailで通知する
Instant Messaging Plugin
Jenkinsとしてはとにかく素早く実行し、フィードバックを
素早く得ることが重要
テストを早い段階で実行、メトリックス測定
ビルドを実行して結果を得るのに48時間かかったらそれまでの間
チームメンバーを待たせてしまって非効率である。
ユニットテスト、受け入れテストについても同じである。
たとえばhtml publisher pluginがある
プラグインはとにかく沢山あり、結果を通知して
メンバー全員に周知を徹底させることができる
コードのクオリティは重要
Sonarはコードメトリクスをはかる良いツール。
Jenkinsでプロダクトをproactive(積極的)に悪い部分を
検出することができる。
自分で事前にルールを設定でき、その閾値を突破したら
ビルドを失敗とマークさせることができる
(Code Coverage80%以上とか…)
これはCodetura Pluginを使った場合。
Jenkinsにプロジェクトのルールを自動的に強制させることが出来る
リリースについて
Choose a release strategy
リリース対象のバイナリを極力容易に識別できるようにすることが重要。
mavenを使っている場合は、リリースプラグインを利用して、リリース候補を
作ればよいが、プラグインが重く操作も難解なのが難点。
継続デリバリではmavenリリースプラグインはイマイチなことも。
コードをチェックインして、テストを通し、スナップショットビルドを作るのも
大切。
そして受け入れテスト、コードメトリクス測定、リリース候補の生成までを行う。
ただし、mavenの場合は、出戻りが発生してまたテスト実行に時間がかかることがある。
(リリースプラグインの実行は手動だから)
別の戦略としてはmvn version:setを使うこと
常にsnapshotビルドを作り続けるけれども、これと決めたバージョンを
リリースバージョンとしてしまうようなアプローチ。
snapshotビルドではなく、リリースバージョンと決めたらあとはartifactoryや
nesusプラグイン(maven repositoryと連携させるためのプラグイン)を使って
出荷できる。
バイナリーのアーカイブには簡単に無償でできるアプローチが2つある。
copy artifactを使うこと。個人的にはartifactoryにリリースするのが好み(も
ちろんデリバリだけでなくデプロイまで自動化することも可能)デプロイメント
チームもオペレーションチームも、デプロイメントプロセスを共有して同じこ
とをすればよい。
puppetなどを使えばそれはもっとシンプルに楽になる。
ビルドプロセスを可視化、見える化したいということ。
特定のコミットがどのプロセスまで進んだのか、どこで
失敗したのかなどを見える化するのが重要。
Rigorous testing and reporting gives us confidence in our product...
高品質のテストは重要で、それによって確信を持って出荷が出来る
その受け入れテストはビジネス価値をもたらすストーリーに基づいているので、コードはビジネス価値をもたらすことが保証されている…
なお、経験的に、自動化できないテストは、ユーザーシナリオ、受け入れテストで
「マニュアル」としてマークしておく。が、その「マニュアル」としてマークされているテストの割合は非常に少ない。
JDBCURLなどの設定→設定を外出しに
