Presented virtually at JAWS DAYS 2019.
はじめに 現代では、ソフトウェアは一般にサービスとして提供され、Webアプリケーション や Software as a Service と呼ばれる。Twelve-Factor Appは、次のようなSoftware as a Serviceを作り上げるための方法論である。 セットアップ自動化のために 宣言的な フォーマットを使い、プロジェクトに新しく加わった開発者が要する時間とコストを最小化する。 下層のOSへの 依存関係を明確化 し、実行環境間での 移植性を最大化 する。 モダンな クラウドプラットフォーム 上への デプロイ に適しており、サーバー管理やシステム管理を不要なものにする。 開発環境と本番環境の 差異を最小限 にし、アジリティを最大化する 継続的デプロイ を可能にする。 ツール、アーキテクチャ、開発プラクティスを大幅に変更することなく スケールアップ できる。 Twelve-F
難関1で示したCIの流れは、あくまでツールの処理である。CIではさらに、開発者が行うプログラミングなどを含めたプロセスやルールが必要になる。これが、二つ目の難関である。 もともとCIは、アジャイル型の方法論の一つである「XP(eXtreme Programming)」で提唱されたプラクティスである。このため短い期間で開発・テスト・実装を繰り返すアジャイル型の開発プロセスと相性がよい。というより、アジャイルではCIの導入はほぼ必須だ。とはいえ、ウォーターフォール型の開発プロセスには適用できないかといえば、そんなことはない。ウォーターフォール型でも導入は可能で、同様のメリットを得られる。 基本的に、アジャイル型とウォーターフォール型でCIのプロセスやルールに違いはない。ただしデリバリーまで含めたCD(Continuous Delivery:継続的デリバリー)と呼ぶ手法を実践する場合はアジャイル
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く