BT

継続的デプロイメントの変数とソリューション

| 作者: Aslan Brooke フォローする 0 人のフォロワー , 翻訳者 笹井 崇司 フォローする 0 人のフォロワー 投稿日 2013年7月24日. 推定読書時間: 2 分 |

原文(投稿日:2013/07/14)へのリンク

今年4月のRubyConf 2013にて、CircleCIの共同創業者であるPaul Biggar氏が "The Many Ways to Deploy Continuously" というプレゼンをした。デプロイメントの頻度は "Continuous" と言うにふさわしい資格を与えるとともに、デプロイメントの問題に直接的な影響を及ぼしている。このプレゼンはCircleCI自身の顧客、Facebook、 IMVU、Etsy、Heroku、Googleから集めたソリューションに関する情報をまとめたものだ。彼らは、いずれの会社も若干異なるデプロイメントを実施していること、継続的にデプロイするためのソリューションは1つではないことを明らかにした。

Paul氏は、いかにデプロイメントソリューションがいかに、コード、データベース変更、デプロイメント単位、デプロイメントのスピード、テスト、モニタリングを伴うプロセスになるか、詳しく説明した。そして、こうしたデプロイメントソリューションの開発に影響を及ぼす変数には、新機能のスピード、コードの複雑さ、ソフトウェアアーキテクチャ、ソフトウェアデザイン、エンジニアの数、モニタリング状態といったものが含まれると語った。

Paul氏は、プロダクションへのデプロイメント中の遷移状態を管理するのによく見られるソリューション、"Race"は新旧機能をサポートしたコードをデプロイメントすることであると説明した。これには機能をプログラムするエンジニアを必要とするが、この結果、新しいコードを古いコードと並行して安全に実行することができる。データベースには格納された状態という課題もある。データベースのバージョンを最終的に変更する前に、まずアプリのその他のところを更新し、両方のバージョンのデータベースを扱えるようにすると十分であるように見えるだろう。ところが、SQLデータベースの変更が大量のロックを引き起こすため、バージョン毎に新しいデータベーステーブルを作ってデータを移行するしか、リーズナブルな選択肢がない場合もある。アプリケーションはまず新しいテーブルをチェックし、もしデータがなければ古いテーブルにフォールバックするよう実装することになるだろう。ロッキングシナリオを回避できるという理由で、NoSQLも人気になっている。 

このプレゼンでは、デプロイメント単位、スピード、テストによる検証、モニタリングによる確認といった側面についても説明している。これらはデプロイメントの非機能要件だが、そのレベルがデプロイメントの継続性度合いを決定付けている。

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする
コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

ディスカッション

InfoQにログインし新機能を利用する


パスワードを忘れた方はこちらへ

Follow

お気に入りのトピックや著者をフォローする

業界やサイト内で一番重要な見出しを閲覧する

Like

より多いシグナル、より少ないノイズ

お気に入りのトピックと著者を選択して自分のフィードを作る

Notifications

最新情報をすぐ手に入れるようにしよう

通知設定をして、お気に入りコンテンツを見逃さないようにしよう!

BT