2016/02/03あなたが「リリース」という言葉を聞いた時、どのような感情が呼び起こされるだろうか?安堵?高揚感?あるいは初めての達成感だろうか?もしあなたのチームがまだ、リリース準備に手作業でのテストや、手作業によるデプロイ、またはスクリプトに部分的にしか頼らないデプロイをしていたとしたら、あなたの感情はむしろ「不安」や「猛烈な怒り」により近いかもしれない。図:手作業デリバリにおける感情のジェットコースターそのため、ソフトウェア開発は「継続性」に向かって進んでいるのである。力を高めようという動きを表している。企業が、こうした変化の意味を模索していくと、必ず継続的デリバリ(一般にCDとして知られる)にたどり着く。誤解してもらっては困るのだが、CDは「ユニコーン」企業1や人気の技術系企業に限ったことではない。つつましい設立間もない企業から古風な企業まで、あらゆる組織における全てのチームが、この継続的デリバリを実践できる。この記事では、継続的デリバリに切り替える上でのビジネスケースを挙げ、この先やるべきことや、継続的デリバリがもたらすメリットについて話すつもりだ。CDの手段を用いたソフトウェア出荷に必要な決断や妥協点(代償)についても説明していこうと思う。全てのチームが継続的デリバリを実践できる。継続的デリバリが企業にもたらす4つのメリット反応がより速くなるCDがもたらす最も顕著なメリットは、社内外の変化に対して素早く反応できるようになることだ。市場状況や経営構造の急な変化、または自社の主力商品の評判が突如下がってしまった時など、極めて重大な変化に素早く対応できるようになる。それを望まない企業なんてあるのだろうか?リスクが軽減される多くの組織において、リリース間近のお祭り騒ぎは多かれ少なかれあるだろう。騒ぐべきではないのか?新機能がやっと顧客に届く。みんなハッピーではないか。リリース出荷には、QAチームとビルド・リリースチームの多大な努力を要するということは、多くの組織で隠されている。継続的デリバリモデルでは、ソフトウェアは常に「リリースされる」ものである(顧客にとっては必ずしも必要というわけではないが)。したがって、リリースにまつわるお祭り騒ぎとリスクが減るというわけだ。常にリリース用インフラを頼っていれば、数週間、または数ヶ月に一度しか工程を経ない場合よりもずっと早く不備に気づき、解消できるだろう。不備やコストが目に見える最新のWebサービスであれ、昔ながらのISOイメージであれ、どのようなソフトウェア企業も、細々とした費用を負担している。多くの場合、こうした経費は会社に完全にオープンになっていない。リリースするのに本当はいくらかかるのかを覆い隠す何らかの力が働いているのかもしれない。継続的デリバリは、この過程を会社そのものに対してだけでなく、意思決定者に対しても見えるようにしてくれる。パイプラインを作るとき、人が関わるのはどの部分か、ボトルネックとなるのは何か、摘み取っておくべき小さな問題は何なのかが明確になる。一度作られたパイプラインは、好循環を起こしていく。今や、堅実にソフトウェアをデリバリできる仕組みがあるのだ。リリースにどのくらいの期間やコストがかかるか分からないという不満はなくなるだろう。リリース時の選択肢がより柔軟になる継続的デリバリモデルへ移行するには、運用の中身とソフトウェアアーキテクチャの中身の両方において、インフラの構築をする必要がある。一度構築を終えてしまえば、機能追加や修正のやり方に柔軟性をもたらしてくれる。特定の機能を特定の顧客にリリースできるかもしれないし、もしくは、それらが設計通りに機能してスケールすることを保証するために、一部の顧客に向けてリリースできるかもしれない。テストして開発したものの、次のバージョンアップリリースを待って製品で眠っている機能もあるかもしれない。会社のマーケティング部が業界の年次コンベンションで「ウケる」製品を望んでいるって?継続的デリバリなら、こうしたリクエストに簡単に応えることができる。継続的デリバリはユニコーン企業だけのものではないこれまで述べてきた企業へのメリットを考えると、継続的デリバリは魔法のように思えるかもしれないが、そうではない。これは単に、ソフトウェアの設計、開発、納品の仕方における考え方を変えただけにすぎない。この変化に続き、実施に向けた取り組みへの集中的な投資が必要となる。多くの組織がCD移行の最初の段階、つまり、CDの投資の価値を定め、実行に移す部分で行き詰まってしまう。いうのも、CDへの移行には、技術的なプロセス、運用における風土、組織の考え方に対する全面的な見直しが必要とされるため、始めるにあたって大きな障害があるように思われやすい。大幅な変更をしたり、何年も放っておかれていたソフトウェアデリバリのインフラ構築をしたりしなければならないため、企業にとってはいっそう腰が重くなるかもしれない。良い点としては、私たち人間には、ことのほか順応性があるということだ。地獄のようなソフトウェアのリリース工程がマシになると聞けば、なおさらやる気になるだろう。会社の様々な場面でCDへの準備を整えておくことで、他の形でも良い影響が出る。CD移行に関して会社の全面的な支持を得られなくても、あなたが出来る範囲で変えていこうとすれば、その中で価値は十分に出てくる。大きな初期投資は、CDへの移行が企業目標として意義があるという合意を周りから得ることだ。この合意は、全員が参加しなければ達成できないものであり、移行期間中は真剣な(だが最終的に有益となる)妥協を要する重要なものだ。「これから数ヶ月、自動テストや自動ビルド・リリースのインフラに取り組んで、アプリケーションがどう書かれているか見直そう。自社の機能開発は後回しだ」こんなことを言うプロダクトマネージャは今まで見たことがない。したプロジェクトマネージャーたちの見解にはうなずける。プロダクトマネージャとビジネス利害関係者を参画させる方法は、一度CDへの投資が実を結び始めたら、新機能のリリースがいかに早くなるかを彼らに証明してみせることだ。PMがアイデアを頭に思い浮かべたらすぐに、イベント分析を搭載した超軽量バージョンの機能を出荷することができる世界を想像してみてほしい。その分析からは、ユーザがその機能を使う上での採択や能力に関するデータが送られ、PMは今後の機能改善のために、そのデータを使用できる。この過程はCDなしでは1ヶ月かかるが、CDを使えば、そのイテレーションサイクルは数日~数週間になり得る。これはCDが稼働するまで、すべての機能開発を中止すべきだと言っているのではない。プロダクトマネージメント、エンジニアリング、エンジニアリングサポート(QA、運用、ビルド・リリース)といった企業のあらゆる部門で、CDのもたらす長期的なメリットが受け入れられるべきだ。この部分は難しいことではない。CD移行に向けて必ず守らなければならない事は、構想が停滞して結局頓挫してしまうことがないよう、常に気をつけることだ。継続的デリバリへの投資を必要とする部門が他にもある。この時点では、CDはきっかけに過ぎないかもしれないが、CDによる変化は他のメリットをも生み出す。自動テストこれは、単体テストだけに焦点を当てているわけではなく、結合テストやシステムテストも含まれている。これらはBambooのようなシステムを使って自動化されるべきだ。私の協業した企業が行った最大の投資の一つでは、特に重要なソフトウェアコンポーネントにおいて、全バグ(バグ全部!)に関連する単体テスト(そして意味をなしたのは統合の時)が必要だった。CD実施のどの段階にいるかに関わらず、こうしたテストは再発バグをすぐに特定するのに役立つ上、直ちにリリースサイクルを短くし、ストレスを減らしてくれる。同じことをゼロから始めたとしたら、6~18ヶ月はかかるだろう。アプリケーションアーキテクチャの変化サービス指向アーキテクチャに移行していくことは必須だ。あなたのソフトウェアがSaaSでないのなら、コンポーネントを個別に出荷できるよう、必要なバージョニングとリリースエンジニアリングとともにコンポーネントアーキテクチャに向けて押し進める必要がある。この時、いわゆる「機能フラギング」と「カナリアリリース」は、こうしたコンポーネント化されたサービスやモジュールで利用できる。これは、こうした複雑なシステムを分離することにより、それぞれのインターフェースがよりよく理解され、チームがコンポーネントを自分たちのサイクルでリリースできるようになることで元が取れる。その上、あなたはCDの準備を整えることができる。ほとんどのチームは、リリースサイクルを4~8回ほどまわせば移行できる。ビルド/テストファームFirefoxウェブブラウザへの機能追加は、毎度かなりのテストを走らせることになる。CPU計算時間で200時間以上も要するため、ビルドにかかる時間は言うまでもない。それぞれのコミットでこれらを実行するためには、相当なハードウェア(そして、場合によってはクラウド)への投資が必要となる。現在のビルド/テストファームには、CDをサポートするための十分なキャパシティを用意しなければならない。することで、開発者のフィードバックループが強化され、様々なオペレーションシステムやブラウザでのテストが容易になる。テストファームのキャパシティ調整は時間がかかるプロセスだが、アマゾン・ウェブ・サービスなどのクラウド・プロバイダがこれに一役買ってくれるだろう。カルチャーの重視CDの実施には根本的に、ある程度のカルチャー改革が必要となる。CDのコア構造はフローを変える「デリバリーパイプライン」であり、人に管理される「ゲート」ではないからだ。この構造の性質が、組織のサイロ思考2を少しずつ崩していくための助けとなるかもしれない。そのため、CD移行を応援する人は、こうしたサイロ思考の人々にCD実施の心構えをさせるよう配慮しなければならない。しなければ、危機を感じたサイロ思考の人々が拒絶してくるかもしれない(そして実際、彼らはCD実施を避けるためなら何でもするだろう!)これもまた長期間かかるプロセスだが、集中的に続くのは2~6ヶ月だ。集中的なスタッフ配備CD移行への牽引力を得るために、CD移行に必要なインフラ整備に絞ってエンジニアやコンサルタントを採用する必要があるかもしれない。それはチームに新たな専門知識を集めるための格好の口実となる。目立った変化を起こすことで、既存のエンジニアが気を悪くすることはない。チームに新しい人を雇うことは、組織を前進させてくれる。一丸となって取り組む中で、チームを素晴らしいCDの新世界へと導いてくれるだろう。臨時のコンサルタントでも、組織のカルチャーを変えやすくする空気を作ってくれるため、ベストな契約期間はやはり2~6ヶ月だ。CDへの旅を始めよう継続的デリバリの実施には、組織全体のチームが変化を起こす必要がある。インフラ、ハードウェア、人材への重点的な投資が必要となる。これら全てを行うには時間を要するが、全て可能なことだ。最初のステップとして、まず認識しておくべきことがある。それは、「安く」、誰かの「20%の時間で」、そして「開発とリリースの合間のちょっとした時間で」継続的デリバリへ移行しようとするのは、わざわざ時間(とその分のお金)をかけて失敗するようなものだということだ。これを、変化し続けるソフトウェア業界に「リアルタイムに」対応できる企業にしてくれる投資として捉えたらどうだろうか。CDは、将来的に利益を生み、結果としてバランスシートの投資分を相殺してくれるはずだ。「夜遅くまで」の残業を物ともしない社員や、全体を見ずに自分の目先にある問題だけに勤しむ人への対応を考えると、その価値は一目瞭然だ。(2016-1-27)※元記事の筆者には直接翻訳の許可を頂いて、翻訳・公開しております。最近、エンジニアの間でにわかに話題になっているのが「ポッドキャスト配信」です。端末にカレンダーを表示しようこれは“コマンドライン・マンデー”シリーズの最初の投稿です。このシリーズでは、毎週月曜日に使えるコマエンジニアがもっと働きやすい環境に!エンジニアに嬉しい福利厚生と導入企業まとめIT関連企業を筆頭に、今やどこの企業の求人を見ても「エンジニア募集中」の文字。1秒間あたり3,000枚の画像(約200GB)を作成し持続している。3」がW3Cの勧告に至ったことで、CSSの縦書きが【2020年版】東京周辺で開催のエンジニア向け技術系カンファレンス日程まとめ【全64件!】2019年ももう終わりです。vs命令型プログラミング~Java8でフィボナッチ、素数、階乗をやってみた~プログラミングには多様な形式やパラダイムがあるが、有名なものを2つ挙げるとしたら、関数型と命令型だろPREV【比較表あり】非エンジニアの人にも知ってほしい。