読者です 読者をやめる 読者になる 読者になる

継続的デリバリー

継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化

継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化


ワンクリックで本番環境へのディプロイやリリースが可能な状態を常に維持して開発を行うということが目標ですが、そこに至るために必要な要素というかプラクティスが多いため、実現することはかなりしんどいな、というのが印象です。ただ、これくらいはやっていかないと、自信を持って、常にリリース可能な製品は作れないというのもわかります。本書は

  • 構成管理(VCS, Maven
  • TDD
  • 受け入れテストの自動化
  • ディプロイ自動化
  • CI等各種ツールの習熟

などを熟知した上で、より効率的な継続的デリバリーを実現のためには、、ということだと思います。私自身まったくそのレベルには至っていないのですが、いくつか印象に残ったことを書いておきます。その他にもDVCSやデーベースリファクタリングやリリース方法など盛りだくさんです。
少し気になる点としては、全体的に文章が多くて、特に前半は同じ事が繰り返し述べられている印象がありました。

ブランチを使わない

VCSを使ってある程度大きな機能追加やリファクタリングを行う場合には、ブランチを切って作業を行うことがありますが、本書は一貫して否定的です。メインラインにマージする時間が遅れるほど問題が起きやすく、大規模な変更を分割して小さくしたうえでインクリメンタルにメインラインにコミットせよということです。

受け入れテストのレイヤー化

私も苦労していますが、、自動の受け入れテストをUIベッタリに書いてしまうと(webであればhtmlのid等をハードコーディングする)、テストコードの変更コストが大きくなりすぎるので、UIを抽象化したレイヤを設けるべき。SeleniumのPageObjectモデルのような考えだと思います。

旧バージョンに戻すとき

何かの理由で旧バージョンに戻すときには、旧バージョンをディプロイし直すか、そもそも旧バージョンを残しておいて切り替えるべき。バージョンを戻すための手作業はダメ。ディプロイもステージング環境と本番とで同じ手順にしておけば、何回も繰り返していることなので安全。