「マンガ読んだ！！」のCI/CDについて
この内容は CI/CD Advent Calendar 2019 - Qiitaの15日目の記事です。僕はマンガ読んだ！！いうサービスを1人で2年半以上作っています（すいません。Azureの課金の問題で最悪今月はサイトに入れないかもしれません）。マンガ読んだ！！は、自分が読んだマンガのログを残すことが出来るマンガログサービスです。
マンガ読んだのバージョン管理とCI/CDについて
マンガ読んだ！！は開発はBlazor、サーバーはAzureでApp Service、バージョン管理はgit、リポジトリはAzure DevOpsを使っています。gitとは言え、ブランチすらも碌に切っていませんでした。理由は、言ってしまえばそれで成り立っていたからです。一人なので当たり前ですが、コンフリクトも殆どしたこともありません。デプロイはVisual Studioから行っています。GUIで選んでボタンを押すだけなので、手動デプロイと言っても簡単なもんです。結論から言うと、一人開発でいえば割り切ってこの運用でも、正直問題ないんじゃないかなと思います。
git flowをどれにするか
ただ、自分自身CI/CDに関しては一過言ある方で、流石にCI/CDもせず、ひたすらmasterブランチ一本というのもどうかと思って、色々設定することに決めました。まずflow戦略から考えました。すなわち、git flowかgithub flowかgitlab flowかです。先ず、個人開発においてgit flowは複雑過ぎるし、手間が増えるだけで、メリットを感じません。選ぶならgitlab flowにするか、github flowにするかです。とりあえずそれぞれのフローを把握した状態ではgitlab flowか一番良さげかなと思っていました。masterにマージしてもデプロイしたくないタイミングもあるだろうし、tagでproductionへマージすればログとしても扱いやすいし。
トリガーとマージ
で、実際Azure DevOpsを設定しながら考えました。まず自動デプロイのタイミングです。Azure DevOpsはgitでmasterへのマージをトリガーに出来ます。でも、masterにマージされるタイミングでチェック走らせたら遅いよなと思いました。だってマージされたときにテスト失敗したらそれはマージする意味がないです。じゃあどうするかというプルリク時にもトリガーが設定できます。プルリク時にCI走らせて、ビルドエラーやテストエラーだったら、そのプルリクは完了しない。つまり、masterにマージ出来ない。これは良い感じです。でもこのタイミングつまりプルリクで完了してない状態でCDされたらそれも困ります。つまりCIとCDでキックして動かしたいタイミングは違います。CIはプルリク開始時が良くて、CDはgithub flowならmasterへのマージ時、gitlab flowならproductionへのマージ時が良いです。
実際の運用
で、実際設定して、さらにプルリク時には、ステージングへのデプロイをやるようにしました。つまりプルリクをした段階でCIが動き出し、このプルリクを完了しようが跳ねられようが、ステージングへのデプロイまで完了します。これで、実運用としては、フューチャーブランチを切って、タスクが実装出来たら、プルリクをする。で、しばらく待っているとCIが完了してステージングへデプロイされます。ローカルチェックで不安の時は、ステージングで状態確認すれば安心感が得られるし、システムテストも可能です。問題ないと思っている時はそのままプルリク承認すれば、それでmasterへマージされます。一旦この状態でmasterへのマージ時に本番へのデプロイもやるようにしました。つまりgithubflowを採用しました。
