BT

昔ながらの企業にDevOpsを導入する

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

原文(投稿日:2013/06/23)へのリンク

Niek Bartholomeus氏は昔ながらの企業における構成管理とリリース管理の実行について、DevOpsにフォーカスした4本のブログ記事を書き上げた。Niek氏はまずDevOpsの理論を紹介し、それから昔ながらの企業におけるソフトウェアデリバリー問題を分析し、最終的に、問題を解決するための具体的なDevOpsプラクティスについて説明している。Niek氏はGene Kim著『The Phoenix Project』を読んでこのブログ記事を書いた。その動機について、彼はこう説明する。

これはGene氏のお伽話とIT懐疑論者の現実との間にある穴を埋めようとするものです。

Niek氏はDevOpsの理論について、協調作業というカルチャーとエンドツーエンドの理解を築きながら、自動化のための支援ツールを使うことで効率のよいプロセスを導入することだと説明した。彼はDevOps導入に対する抵抗勢力(対立する関心を守るチーム、変化と安定との間にある競合、よく見られる変化に対する抵抗運動)について分析した。こうした課題があるにも関わらず、彼の話のDevOpsプラクティスは特に、ソフトウェアデリバリーの複雑さ(最悪の場合、拡張性がなく、手作業の労働力を要するプロセスになる)を克服することをターゲットとしている。

Niek氏は3番目のブログ投稿で、構成管理の導入について書いた。彼はそこで、ビジネス応用、変更要求、ソフトウェアコンポーネント、デプロイメント要求、リリースの間にある関係を正確に管理することの必要性について述べた。最後の投稿でNiek氏は、リリース管理の導入と前に紹介した構成管理ツールとの統合について述べた。彼の最終的な概念図は次のようになる。

 

継続的デリバリーやゼロダウンタイムなどのさらに進んだDevOpsプラクティスには漸近的な変化が必要であり、昔ながらの企業にはまだ準備ができていないことを認めた。しかし、彼による最初のステップは企業をそう方向付けるものだ。彼は次のように述べた。

従来のソフトウェアデリバリープロセスを徐々にコントロールし、可能なところを自動化して徐々にリリース頻度を高めることができれば、おそらくいつか、継続的デプロイメントへの跳躍は恐れるものではなくなるかもしれません。

DevOpsプラクティスを導入するための作業は、複数の現実世界の問題を解決するのに貢献すると言って、話を締めくくった。そうして得られた環境は、自動化され、首尾一貫し、コントロールされ、適切に調整されたものになる。だが、特にテストの領域にはやるべきことがまだまだあると彼は考えている。

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには 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