[lt] continuous delivery
DESCRIPTION
部署内のContinuous Deliveryの説明資料TRANSCRIPT
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/