CI を詳しく見てみると、疑問が生じました。アジャイル開発プロセスは、継続的インテグレーションを使用できるようにするための前提条件ですか?
従来のチームベースの開発プロセスに CI プロセスを実装することは可能でしょうか?
敏捷性は多かれ少なかれ前提条件であると私は直感的に言いますが、「直感」は経営陣と話すときの議論ではありません... :-)
そして、これに関するドキュメントはありますか?私が見つけたのは、あなたがすでにアジャイルに取り組んでいることを当然のことと考えていることだけです。
CI を詳しく見てみると、疑問が生じました。アジャイル開発プロセスは、継続的インテグレーションを使用できるようにするための前提条件ですか?
従来のチームベースの開発プロセスに CI プロセスを実装することは可能でしょうか?
敏捷性は多かれ少なかれ前提条件であると私は直感的に言いますが、「直感」は経営陣と話すときの議論ではありません... :-)
そして、これに関するドキュメントはありますか?私が見つけたのは、あなたがすでにアジャイルに取り組んでいることを当然のことと考えていることだけです。
アジャイル プロセスに従っているかどうかに関係なく、ほぼすべての開発チームで継続的インテグレーションが優れたプラクティスであると私は主張します (ソース管理と無料のコーヒーと共に)。私はアジャイル チーム、従来型のチームで使用してきました。また、一人でコーディングしている場合でも、常に付加価値がありました。
あらゆる開発プロセスで、CI は以下を提供します。
Jenkinsを見てみましょう。これは無料で、セットアップも非常に簡単です。
CI は実際にはアジャイルまたは非アジャイルの方法論とは関係ありません (ただし、CI を要求する州もあれば、間接的にほのめかすか、まったく言及しない州もあります)。
CI は、開発中にいくつかのバグをできるだけ早く排除するのに役立つ唯一のツールです (キーボードのようなものだと思います)。
実際にCIを行う必要があるのは、ビルドツール(ポストコミットフックなど)を使用してバージョン管理システムを構成し、すべての開発者にコードがコンパイルされることを確認したらすぐにコードをコミット/フェッチするように依頼することだけです-これで十分です継続的インテグレーションを開始すると、もちろん単体テストなどを追加できます
したがって、答え -アジャイルは要件ではなく、XP、スクラム、その他の方法論を実装しなくても、どのプロセスでも CI を実装できます。