部署内のContinuous Deliveryの説明資料

1. Con$nuous
Delivery(CD)
継続的デリバリー
@bae_j

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

3. 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

4. で、何だよ？
• ユーザのフィードバックを高速に回す
• 儲かります
• もう一度言います！
儲かります！

5. なぜ儲かるの？
• 事業的には
– 事業の評価が速いから戦略修正も早い
– リスクが小さい
• IT部門には
– 実際の反応が得られる
– 個別リリースのリクス回避ができる

6. まだまだのあなたのために
h=p://www.ryuzee.com/contents/blog/4241

7. まだまだのあなたのために2
h=p://www.informit.com/ar$cles/ar$cle.aspx?p=1641923&seqNum=3

8. CDはいいんだ！実践方法は？
• まずはこんなの読んでみましょう。
• 8
Principles
of
Con$nuous
Delivery
• 大丈夫日本語もあります。ここ

9. 8
PRINCIPLES
OF
CONTINUOUS
DELIVERY

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

11. 2.
Automate
everything!
• 手動デプロイは犯罪！とは言ってないですが犯罪だと思います。
• 自動化に本気で投資しろ！

12. 3.
If
somethings
difficult
or
painful,
do
it
more
oOen.
• 馬鹿なこと言うな！じゃなくて辛い作業が改
善へ導く
– キレたB氏の事例
• Antでビルドすると面倒いからMaven化
• ビルドがあちこちでビルドされるからJenkinsでビルド
• Deploy時間掛かるからFabricで時間を短くする

13. 4.
Keep
everything
in
source
control
• 当たり前！
• 本当に？
– 本番のDBアクセスキーは？

14. 5.
Done
means
“released”.
• 実装完了は完了ではない。
• リリースされてユーザが実際に問題なく使う
時点から完了って言える。
• Q.
うちではどうすればこれが言えるでしょう
か？

15. 6.
Build
quality
in!
• 品質(quality
metrics)に投資しろ！
– Unit
test
coverage
– Code
style
check
– Rules
viola$on
– Complexity
measurement
• Sonar使いましょう

16. 7.
Everybody
has
responsibility
for
the
release
process.
• ローカル環境のあなたのアプリケーションは
金にならない！
• リリースされてから価値は生まれる
• その価値を生むためにPDM,
QA,
開発者の力
が必要且つ責任です。

17. 8.
Improve
con$nuously.
• 引かない！
• システムがメンテー不能になるまで待たな
い！
• 継続的改善でシステムをモダーンにする

18. 4
PRACTICES
OF
CONTINUOUS
DELIVERY

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

20. 2.
Use
precisely
the
same
mechanism
to
deploy
to
every
environment.
• 当然の話ですが、STGと本番は同じ手順でデ
プロイする！

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

22. 4.
If
anything
fails,
stop
the
line!
• 途中で失敗したら全部止める
• 一旦ロールバック
• 最初から問題を解決してまたデプロイする

23. B氏のCDは？
• 面倒いから手で図書きます。

24. 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/