Con$nuous  Delivery(CD)  継続的デリバリー  

@bae_j  

継続的デリバリーとは  Con$nuous  DeliveryとはリリースのスケジュールをIT部門が握るのではなく、ビジネス部門が握るということだ。 Con$nuous  Deliveryを実装するということは、全体のライフサイクルを通じて常にソフトウェアが本番環境にリリース可能であるということを意味する。すなわちどのビルドもボタン一発で、完全に自動化されたリリースプロセスを通じて、秒とか分の時間で利用者にリリース可能である、ということだ。  Jez  Humble  h=p://www.ryuzee.com/contents/blog/4241  

What  Is  Con$nuous  Delivery?  Crea$ng  a  $ght  feedback  loop  between  your  users  and  the  project  team—including  the  customer  or  product  owner—relies  in  turn  on  being  able  to  con$nuously  deliver  new  versions  of  your  soOware  to  test  changes  and  new  ideas,  and  being  able  to  measure  the  effect  of  these  changes  on  your  revenue.    For  many  companies  that  are  used  to  releasing  new  versions  of  soOware  at  most  every  few  months,  the  idea  of  releasing  changes  several  $mes  a  day  seems  impossible.  However,  at  ThoughtWorks,  we  have  used  the  principles  and  prac$ces  described  in  my  book  Con$nuous  Delivery  to  help  organiza$ons  that  released  a  few  $mes  a  year  move  to  releasing  several  $mes  a  month,  or  even  more  frequently.  That  represents  a  huge  compe$$ve  advantage,  and  it  means  a  large  reduc$on  in  the  amount  of  wasted  $me  and  effort  in  your  IT  organiza$on.    h=p://www.informit.com/ar$cles/ar$cle.aspx?p=1641923  

で、何だよ？  

•  ユーザのフィードバックを高速に回す  

• 儲かります  

• もう一度言います！儲かります！  

なぜ儲かるの？  

•  事業的には  – 事業の評価が速いから戦略修正も早い  – リスクが小さい  

•  IT部門には  – 実際の反応が得られる  – 個別リリースのリクス回避ができる  

まだまだのあなたのために  

h=p://www.ryuzee.com/contents/blog/4241  

まだまだのあなたのために2  

h=p://www.informit.com/ar$cles/ar$cle.aspx?p=1641923&seqNum=3  

CDはいいんだ！実践方法は？  

•  まずはこんなの読んでみましょう。  •  8  Principles  of  Con$nuous  Delivery  •  大丈夫日本語もあります。ここ  

8  PRINCIPLES  OF  CONTINUOUS  DELIVERY  

1.  The  process  for  releasing/deploying  soOware  MUST  be  repeatable  and  reliable.    

2.  Automate  everything!  

•  手動デプロイは犯罪！とは言ってないですが犯罪だと思います。  

•  自動化に本気で投資しろ！  

3.  If  somethings  difficult  or  painful,  do  it  more  oOen.  

•  馬鹿なこと言うな！じゃなくて辛い作業が改善へ導く  – キレたB氏の事例  

•  Antでビルドすると面倒いからMaven化  •  ビルドがあちこちでビルドされるからJenkinsでビルド

•  Deploy時間掛かるからFabricで時間を短くする  

4.  Keep  everything  in  source  control  

•  当たり前！  •  本当に？  – 本番のDBアクセスキーは？  

5.  Done  means  “released”.  

•  実装完了は完了ではない。  •  リリースされてユーザが実際に問題なく使う

時点から完了って言える。  •  Q.  うちではどうすればこれが言えるでしょう

か？  

6.  Build  quality  in!  

•  品質(quality  metrics)に投資しろ！  – Unit  test  coverage  – Code  style  check  – Rules  viola$on  – Complexity  measurement  

•  Sonar使いましょう  

7.  Everybody  has  responsibility  for  the  release  process.  

•  ローカル環境のあなたのアプリケーションは金にならない！  

•  リリースされてから価値は生まれる  •  その価値を生むためにPDM,  QA,  開発者の力

が必要且つ責任です。  

8.  Improve  con$nuously.  

•  引かない！  •  システムがメンテー不能になるまで待たな

い！  •  継続的改善でシステムをモダーンにする  

4  PRACTICES  OF  CONTINUOUS  DELIVERY  

1.  Build  binaries  only  once.    

•  各バージョンは一度だけビルドする。  – Maven  release  pluginが担保  – 各環境用の設定ファイルはどうする？  – wsdlは？  

2.  Use  precisely  the  same  mechanism  to  deploy  to  every  environment.    

•  当然の話ですが、STGと本番は同じ手順でデプロイする！  

3.  Smoke  test  your  deployment.    

•  B氏の事例  – Chefでmiddlewareをupdate  – 正常終了したのでアプリケーション再起動  – 45台のサーバの中1/3の確率でエラーを返す  – 1/3のサーバでmiddlewareはupdateされてない  – middlewareのpidチェックまたは機能確認手順がcookbookにあればよかった  

4.  If  anything  fails,  stop  the  line!  

•  途中で失敗したら全部止める  •  一旦ロールバック  •  最初から問題を解決してまたデプロイする  

B氏のCDは？  

•  面倒いから手で図書きます。  

Reference  

•  Con$nuous  delivery  – h=p://books.rakuten.co.jp/rb/11603145/  

•  h=p://www.informit.com/ar$cles/ar$cle.aspx?p=1641923  

•  h=p://www.informit.com/authors/bio/e0306367-­‐da75-­‐4f0f-­‐86a0-­‐14327a2ae568  

•  h=p://devlove-­‐kansai.doorkeeper.jp/events/10612  

•  h=p://www.ryuzee.com/contents/blog/