ThoughtWorks社がCruiseをリリース:継続インテグレーションとリリースの管理システム
継続インテグレーションはアジャイルのプラクティスであり、コミットされた一つ一つのコードの変更は自動的にビルドとテストが行われる。バグが取り込まれるとすぐにその多くを見つけることで、バグにかかるコストが削減される。
継続インテグレーションはアジャイルのプラクティスであり、コミットされた一つ一つのコードの変更は自動的にビルドとテストが行われる。バグが取り込まれるとすぐにその多くを見つけることで、バグにかかるコストが削減される。
チームが新しい習慣を身に着けようとして、なかなかうまくいかないときがある。習慣とは、ユニットテストを書く、コンパイラの警告をなくす、ビルドを壊さない、などのことだ。どうしたら、チームにこうした習慣を植え付けることができるだろうか?Clint Shankはメンバーを移行させるために、あるゲームをデザインした。
Subversionはマチュアなオープンソースバージョンコントロールシステムで、多くのオープンソースプロジェクトで使用されている。新機能が加わりバージョン1.5がリリースされた。
バージョン管理を厳密におこなうことがないので、すべてのチームのアジリティが激しく危険にさらされている。自由にリファクタリングをおこなう能力、安全に実験する能力、エラーから迅速に回復する能力は、安全網なしで構成されている。多くのアジャイル提議者は、バージョン管理を中心となる実務と位置づけている。
ある夜の夕食のときに、ベテランの実践者たちのグループは、自分たちがチームで「ふりかえり最優先条項」をどのように使用するか(あるいは使用しないか)に関して意見を交換した。
原則として、データベースに対する作業は必ずバージョン管理しなければならない、と強く主張した記事を投稿した後で、Scott Allen氏はデータベースのバージョン管理を最大限に利用する手法について詳しく述べている。彼は、ベースラインを作成し、スキーマのリビジョン管理に変更スクリプトを使い、データベースの(ビューやストアドプロシージャ、ファンクション、トリガ等の)プログラムされたオブジェクトを管理し、そしてブランチやマージ処理を利用する、包括的で実用的な手法を紹介している。
StelligentのPaul Duvall氏は最近の記事で、継続的インテグレーションを継続的リリース(Continuous Production)に成長させるために必要なアクティビティについて書いている。継続的リリースとはまとめてリリースする代わりに、絶えずソフトウェアをリリースし続けるプラクティスのことである。
「完了」と「シップ可能」との相違について、アジャイルに関するさまざまなフォーラムやブログで活発な討論が起こっている。両者は同じことを意味するような気がするが、リストやさまざまなブログ上での討論が提言するのは、この2つはいまなお広範囲にわたって誤解されており、誤使用されている用語であるということである。これは「完了」の取り扱い方についての提案をまとめたものである。