ウェブアプリケーションなどサーバー上で動作するものは、サーバー上にそのアプリを置く必要があり、それをデプロイと呼びます。 この章では、実は大変な作業であるデプロイについて解説します。
リリースとは、新しい機能やアプリをユーザーにお披露目する、公開するという意味であり、デプロイは一般的にリリース作業の中の1手順です。
デプロイはサーバーにアプリを置くための作業なので、当然サーバーが必要になります。
いまどきであればFirebase Hostingのような静的ファイルを置くものや、FunctionsというFaaSと呼ばれるサービスやAmazon AWSの、EC2やLambdaなどクラウドサービスを使います。
昔からやっているような会社ならばデータセンターと契約していたり、会社に専用線を引いて、会社にあるサーバーを使うかも知れません。そういった自前でサーバーを構築することをオンプレミスと呼びます。
インフラエンジニアがデータセンターや社内のサーバールームで、サーバー機を設置したりOSをインストールしたりする必要があるため、本書の取り扱う範囲とはずれることと、現代ではオンプレミスでの運用は減っているため、クラウドサービスを前提とします。
リリースに必要な工程は色々とあります。
- リリース計画を行う
- リリース計画に沿って開発とテスト、QA（品質保証）などを行う
- リリース判定を行う
- デプロイをする
- 問題が生じれば巻き戻しを行う
- 必要があればユーザーに告知する
個人開発だとほとんど関係ありませんが、企業やチーム開発では、リリース計画はとても重要です。
たとえば偉い人がノリだけで「20xx年xx月に○○をリリースします！」と発表をしたり、顧客に突然約束をして、開発チームに不意打ちを食らわせるようなことがあります。特にワンマン社長や営業が権力を持っている会社、あるいはゲーム開発に見られがちです。こういった開発は大体日付だけが決まっているもので、それが本当に開発可能かどうかを正しく判定できていないことがしばしばです。世の中においてデスマーチと呼ばれる悪質な労基法違反が生じる原因の1つです。場合によっては人が死んだりメンタルが壊れたりし、日本語の「過労死」は世界でも有名な言葉 "Karoshi" として知られるようになりました。
基本的には、顧客・ユーザーにどのように価値を届けるかを最大化するために、無理の無いリリース計画を行わなければなりません。価値の最大化は、決して社長の思いつきによって成されるものではありません。場合によっては短期的に成功することもありますが、少なくとも長期的に見たときには、人材を使い潰すとろくなことはありません。またソフトウェア開発関係者は、それがダメだということを知らしめる義務、職業倫理があります。
一般的には定期的なサイクルとしてリリース計画が行われます。一番頻繁なものでは、小さな修正や機能追加を、一日に何回も行うような組織もあります。短めのサイクルとしては1〜4週間、普通の範囲としては3〜6ヶ月、長めのものとしては1年以上です。
ソフトウェア開発はあらゆる意味で不確実性との戦いです。ビジネスには答えはありません。 もし答えがあればそのジャンルはレッドオーシャンどころではなく、もう誰かが完全にそのジャンルを制覇して、新規参入の余地も無いでしょう。 不確実だからこそチャンスがあるのです。
作業工数の見積もり予測は意外に大変です。ある程度以上の規模の作業工数の予測精度を上げる為には、 情報収集と見積もりの時間が必要ですし、バッファ1を確保したりしなければいけません。 もしかしたら人員の誰かが風邪をひくかもしれませんし、冠婚葬祭などあるかもしれません。
ビジネス環境の変化により、予定していた機能開発が不要になったり、機能追加が必要になったりすることもあるでしょう。
つまり、近いスパンの予測はある程度確実性もありますが、長いスパンの予測というのはどんどん不確実になるものです。
リリースサイクルが1年以上のものでは「それだけ長い期間かけて開発してるんだから、これも一緒に開発してよ」といって、リリースが遅れる現象が多発することもあります。
短期計画と中期計画と長期計画を使い分けるという考え方もあります。短期計画はスプリントとかイテレーションと呼ばれるもので管理し、中期計画や長期計画ではそれら短期計画を組み合わせつつ、方向性を整えていくのです。
また、デプロイを含めたリリース工程がどれくらい自動化されているか？によって短いリリースという考え方が可能がどうかが決まります。 リリースに手間が掛かるのであれば、2週間のイテレーションごとのリリース、あるいは1日に何回もリリースするというようなことは夢のまた夢です。
リリース工程をなるべく自動化してリリース負荷を下げる考え方として、CI/CDがあります。 CIはContinuous Integration（継続的インテグレーション）の略で、CDはContinuous Delivery（継続的デリバリ）の略です。
Gitリポジトリにソースコードをコミットすると、それをトリガーとしてさまざまな処理を走らせます。
- 自動テスト
- Linter
- ビルド（コンパイルなど）
- 他検査ツールなど
こういったCIの結果は、たとえばGitHubのプルリクエストに反映されたり、Slackに結果が流れたりします。
またCIの結果問題がなければ、ステージング環境と呼ばれるような環境に自動でデプロイされるようにしておけば、 コミットした結果も気軽に、動作を実際に動かして確認ができます。
これらが実現できればあとは1ボタンで本番リリースと、取り下げも簡単に実現可能でしょう。 実際の機能リリースはエンジニアリングの観点ではなく、ビジネス的理由によって可能になります。
以前であればJenkinsのようなものが使われていましたが、Jenkinsは設定が仰々しすぎるため、 より簡単かつ、GitHubなどと連携がしやすいものが好まれる傾向があります。 一番の有名どころではCircleCIです。1ファイルの設定ファイルをリポジトリに入れるだけでCI/CDが動くため、 お手軽ゆえにOSSなどでも盛んに利用されています。 これらの問題点は、忙しいときは結果が出るまでに待たされることがあることです。 課金によってそういった待ちが緩和されるものもあります。 GitHub自体に統合されたGitHub Actionsはまだβバージョンですが、今後は本格的に利用されているでしょう。 また、GCP/AWS/Azureのようなクラウドの、CI/CIサービスも使われることがあります。
デプロイはどうやって行うか？というと利用しているサービスや、サーバーソフトウェアによってまちまちですが、一般的にはHTTP/HTTPS REST APIを使います。scpやFTPでファイルを送信するようなケースも残っているでしょう。
勉強会に参加したことのある方なら、「ピザがデプロイされました」というTweetを見かけたことはありませんか？
勉強会も佳境です。おなかもすいてきましたね。おっと、ピザやお酒が準備されています。誰かがツイートします。
「ピザがデプロイされました」
「デプロイ」という言葉を知らなかった私は意味を調べます。展開される・・・hm。ニュアンスはわかるけれど・・・リリースじゃないの？ひとしきり悩みます。
ですが、ピザの前にはそんなことは些細な悩みです。
何回か勉強会を経験をして、こういう形で納得することにしました。
ピザを準備(まさに展開)して、ふたを開けるところまでがデプロイ。
だけど、ツイートしているときは、まだ食べられませんから、リリースとは言えません。
乾杯をして、手に取れるようになったら、リリース。乾杯がリリースの合図です。
だからやっぱりピザについてツイートするのは、デプロイなんです。
認識間違ってたらツッコミください・・・
bot作成初心者の私にとって楽しい瞬間は機能が正常に動作したときであった。自分で作成したbotがエラーなく動作していることに達成感や楽しさを感じる方も多いのではないだろうか。ある程度作成を進めてゆくと身近な人に見てもらいたくなった。そう、デプロイにチャレンジしたのだ。私はherokuなどのデプロイツールは全く触れたことがなく、時間がかかってしまいbot作成そのものが嫌いになりそうだった。
そこである程度経験のあったLinuxPC(Ubuntu18.04)を構築した。LinuxPC上でRubyのslack bot開発環境を立ち上げ、ローカルサーバを起動しbotを起動した。現在の流行りの技術にはそぐわない方法でのデプロイではあったが、それよりも「物を形にして第三者に見てもらう」ことを最優先に考えた。実際にLinuxPCでのデプロイも成功しエンジニアの先輩に使ってもらいいくつかのフィードバックをもらうことができた。
初心者がやる気を削がない個人プロダクト作成を行う時は何にモチベージョンを感じるかを考え、そのほかの内容に関しては最低限の内容で済ませる方法が良いのではないかと思う。 本件を通しての感想は「最新技術の勉強を全て網羅してから作成するより段階を踏んでステップアップしてゆくことの大切さを学んだ」である。今後はherokuを用いてデプロイを行う予定である。
Footnotes
-
バッファはこの場合緩衝材などを意味するもので、見積もりのズレを吸収するため、余分な日数をいれておくような手法です。 ↩