<h2 id="%E3%81%AF%E3%81%98%E3%82%81%E3%81%AB">
<a class="header-anchor-link" href="#%E3%81%AF%E3%81%98%E3%82%81%E3%81%AB" aria-hidden="true"></a> はじめに</h2>
<p>本記事はプロもくチャット Adevent Calendar2023の15日目です</p>
<p><span class="embed-block zenn-embedded zenn-embedded-card"><iframe id="zenn-embedded__274f1cc0f1151" src="https://embed.zenn.studio/card#zenn-embedded__274f1cc0f1151" data-content="https%3A%2F%2Fqiita.com%2Fadvent-calendar%2F2023%2Fpuromoku" frameborder="0" scrolling="no" loading="lazy"></iframe></span><a href="https://qiita.com/advent-calendar/2023/puromoku" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://qiita.com/advent-calendar/2023/puromoku</a></p>
<h2 id="%E3%81%93%E3%81%AE%E8%A8%98%E4%BA%8B%E3%81%AE%E7%9B%AE%E7%9A%84">
<a class="header-anchor-link" href="#%E3%81%93%E3%81%AE%E8%A8%98%E4%BA%8B%E3%81%AE%E7%9B%AE%E7%9A%84" aria-hidden="true"></a> この記事の目的</h2>
<p>ちょうど仕事でGutHub ActionsでCI/CDを構築しているので、その勉強のためにCI/CDとはをまとめ、理想のCICDパイプラインを考察してみます<br>
誰かの参考になれば幸いです！</p>
<h2 id="ci%2Fcd%E3%81%A3%E3%81%A6%E3%81%AA%E3%82%93%E3%81%9E%E3%81%84%E3%82%84%EF%BC%9F">
<a class="header-anchor-link" href="#ci%2Fcd%E3%81%A3%E3%81%A6%E3%81%AA%E3%82%93%E3%81%9E%E3%81%84%E3%82%84%EF%BC%9F" aria-hidden="true"></a> CI/CDってなんぞいや？</h2>
<p>そもそもCI/CDってどういった目的を持って利用されるのかを確認してみましょう！</p>
<p>CIとは継続的インテグレーション、CDは継続的デリバリー/デプロイの略です。<br>
CDが継続的デリバリーとデプロイの2つ書いているのは、一応意味が異なるからです</p>
<ul>
<li>継続的デリバリー：本番環境のデプロイまでは行わず、直前まで準備します</li>
<li>継続的デプロイ：本番環境へのデプロイまで自動で行う意味があります</li>
</ul>
<p>細かいことを言ってしまいましたが、CI/CDの大きな目的は <strong>プロダクトの変更をなるべく早く市場に届ける</strong> ことだと私は考えています！！！！</p>
<p>開発はなんのために行うかというと、プロダクトをより良くするためですよね？<br>
プロダクトを良くすることで利益を増やしたり、他者よりも早く新機能を提供することで差別化を行い利益を増やしたりすることが会社としての目的のはずです！<br>
（社会貢献という観点もありますが、売上と利益がなければ事業が続かないのでいったんはおいておきます）</p>
<p>また、実際に市場に出してみたら顧客が求めていたものとは違っていた場合、高速でプロダクトの変更ができれば方向修正もやりやすいですよね！</p>
<p>CI/CDの目的はなんとなくわかったわい！というところだと思いますが、ソフトウェア開発においてCI/CDが出てくる場面が曖昧な人がいるかもしれません<br>
なので、ソフトウェア開発の流れをおさらいします！</p>
<h3 id="%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E9%96%8B%E7%99%BA%E3%81%AE%E6%B5%81%E3%82%8C">
<a class="header-anchor-link" href="#%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E9%96%8B%E7%99%BA%E3%81%AE%E6%B5%81%E3%82%8C" aria-hidden="true"></a> ソフトウェア開発の流れ</h3>
<p>ソフトウェア開発はどういった流れなのかを確認してます！<br>
この記事ではSier的な納品する形ではなく、WEB系企業のように社内で開発から運用まで行っていることを前提とします</p>
<p>すると、大枠は以下のような流れになると思います！（ツッコミ待ってます！</p>
<ol>
<li>要件を決める</li>
<li>実際にどう実現するか設計する</li>
<li>プログラムを実装する</li>
<li>動作に問題がないかテストする</li>
<li>デプロイする</li>
</ol>
<p>上記のなかれ、要件を決めたり設計をしたりという部分は人がいろいろ考えないといけない部分です。<br>
実装する部分も、<code>GitHub Copilot</code>などがありつつもまだ人がいろいろ手を動かさないといけない部分ですね。</p>
<p>ただ、テストはテストコードを書いてしまえば自動で何度もできますし、デプロイもそうそう手順が変わるものではないので自動化できます。<br>
つまりCIとCDが出てくる場面です！</p>
<h2 id="%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E9%96%8B%E7%99%BA%E3%83%97%E3%83%AD%E3%82%BB%E3%82%B9%E3%81%AB%E3%81%8A%E3%81%91%E3%82%8Bci%2Fcd">
<a class="header-anchor-link" href="#%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E9%96%8B%E7%99%BA%E3%83%97%E3%83%AD%E3%82%BB%E3%82%B9%E3%81%AB%E3%81%8A%E3%81%91%E3%82%8Bci%2Fcd" aria-hidden="true"></a> ソフトウェア開発プロセスにおけるCI/CD</h2>
<p>CIとCDについて寄り詳細に見ていきつつ、どういった要素を実現する必要があるか見てみます！</p>
<h3 id="continuous-integration%EF%BC%88%E7%B6%99%E7%B6%9A%E7%9A%84%E3%82%A4%E3%83%B3%E3%83%86%E3%82%B0%E3%83%AC%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%EF%BC%89%E3%81%A8%E3%81%AF%EF%BC%9F">
<a class="header-anchor-link" href="#continuous-integration%EF%BC%88%E7%B6%99%E7%B6%9A%E7%9A%84%E3%82%A4%E3%83%B3%E3%83%86%E3%82%B0%E3%83%AC%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%EF%BC%89%E3%81%A8%E3%81%AF%EF%BC%9F" aria-hidden="true"></a> Continuous Integration（継続的インテグレーション）とは？</h3>
<p>どういったことをCIでしていくと良いかですが、私は <strong>デプロイする前にできることは全部する</strong> ことができればいいと思っています！</p>
<p>具体的には、以下のような要素が必要と考えています</p>
<ul>
<li>必須
<ul>
<li>コンテナイメージのビルド
<ul>
<li>ビルドはデプロイ前に必須ですね！</li>
</ul>
</li>
<li>テストの実行と結果レポート
<ul>
<li>新機能のテスト</li>
<li>既存機能に影響がないかリグレッションテスト</li>
</ul>
</li>
</ul>
</li>
<li>あると良さそう
<ul>
<li>静的コード解析
<ul>
<li>コードの品質や信頼性、セキュリティ検証</li>
</ul>
</li>
<li>コンテナのセキュリティスキャン
<ul>
<li>DockleやTribyでDockerベストプラクティスに沿っているか、脆弱性を含むパッケージがないかスキャン</li>
</ul>
</li>
<li>コードカバレッジの計測
<ul>
<li>ソースコードがどれくらいテストされているか</li>
<li><a href="https://zenn.dev/shu_illy/articles/b4e635730c5ec0" target="_blank">アドベントカレンダーでリリーさんが書かれていたような内容です！</a></li>
</ul>
</li>
<li>Formatter実行
<ul>
<li>コードスタイルを統一して、可動性を上げる</li>
</ul>
</li>
</ul>
</li>
</ul>
<p>実際にデプロイする前に問題を見つけることができれば、早く修正できて手戻りが少なくて済みます<br>
また、CIとして自動で実行されるようにしておけば、「あっ！実行し忘れたまま本番環境までデプロイしちゃった💦」ということを防ぐことができます！</p>
<p>仕組み化で、意識しなくても良くした方が楽そうです</p>
<h3 id="continuous-deployment%2Fdelivery%EF%BC%88%E7%B6%99%E7%B6%9A%E7%9A%84%E3%83%87%E3%83%97%E3%83%AD%E3%82%A4%E3%83%A1%E3%83%B3%E3%83%88%2F%E3%83%87%E3%83%AA%E3%83%90%E3%83%AA%E3%83%BC%EF%BC%89%E3%81%A8%E3%81%AF%EF%BC%9F">
<a class="header-anchor-link" href="#continuous-deployment%2Fdelivery%EF%BC%88%E7%B6%99%E7%B6%9A%E7%9A%84%E3%83%87%E3%83%97%E3%83%AD%E3%82%A4%E3%83%A1%E3%83%B3%E3%83%88%2F%E3%83%87%E3%83%AA%E3%83%90%E3%83%AA%E3%83%BC%EF%BC%89%E3%81%A8%E3%81%AF%EF%BC%9F" aria-hidden="true"></a> Continuous Deployment/Delivery（継続的デプロイメント/デリバリー）とは？</h3>
<p>CDでは、文字通りデプロイするorデプロイができる状態にすることをが目的です。<br>
CDとして仕組み化することで、デプロイ手順は毎回同じ品質で実行されるようになるため、ミスが減ります！</p>
<p>コンテナかつAWSであれば<code>ecspresso</code>や、CodeDeployなどで実現できます！</p>
<h3 id="ci%2Fcd%E3%81%AE%E5%A4%A7%E5%A4%89%E3%81%AA%E3%81%A8%E3%81%93%E3%82%8D">
<a class="header-anchor-link" href="#ci%2Fcd%E3%81%AE%E5%A4%A7%E5%A4%89%E3%81%AA%E3%81%A8%E3%81%93%E3%82%8D" aria-hidden="true"></a> CI/CDの大変なところ</h3>
<p>CI/CDで実現できる良い点について色々書いてきました。<br>
CI/CDはどんどんやっていこうと思うかもしれませんが、大変な点もいくつか存在します<br>
それは、<strong>CI/CDの維持と改善</strong> です。</p>
<p>何か仕組みを用意するということは、維持する活動をしなければ形骸化したり動作しなくなったりすることは目に見えています。<br>
ちゃんと維持していくなら、必要な知識を持った人を用意して、継続的に運用できる体制にしておく必要があります！</p>
<p>また、チームがアプリケーションとインフラで分かれていると責任分界点が生じやすく、どちらでもない領域が発生してやりづらさが出てくることもあります（私は実際に経験しています</p>
<h2 id="%E6%84%8F%E5%A4%96%E3%81%A8%E5%A4%A7%E4%BA%8B%E3%81%AA%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E6%88%A6%E7%95%A5">
<a class="header-anchor-link" href="#%E6%84%8F%E5%A4%96%E3%81%A8%E5%A4%A7%E4%BA%8B%E3%81%AA%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E6%88%A6%E7%95%A5" aria-hidden="true"></a> 意外と大事なブランチ戦略</h2>
<p>CI/CDについて書いて来たのですが、実は意外と考慮しないといけないものとして<code>ブランチ戦略</code>があります</p>
<p>体表的なブランチ戦略としては、<code>Gitフロー</code>、<code>GitHubフロー</code>、<code>GitLabフロー</code>などがあります</p>
<p>ブランチ戦略によって、このブランチではCIを実行する、このブランチでは開発環境へデプロイする、このブランチではステージング環境にデプロイしてE2Eテストと負荷試験を実施するなど色々考慮する必要ができます！<br>
なので、ブランチ戦略とCI/CDは密接に結びついてきます！</p>
<p>具体的にGitHubフローで考えてみます。<br>
GitHubフローでは基本的に<code>main</code>と<code>feature</code>ブランチが存在しますが、環境がdevelopment/staging/qa/productionと存在する場合、いつデプロイを実行するかをちゃんと決めないとごちゃつきます。<br>
<code>feature</code>ブランチでは開発環境、<code>main</code>ブランチでは本番環境にデプロイすると決めれば運用はできますね。<br>
ただ、本番環境相当のデータ量とリソースサイズで試験をしたいけど、開発環境ではできないから環境を用意してくれという要望が出てきた場合、どうすればいいかは悩みどころです...</p>
<p>どういった環境を用意して、それぞれにどういった役割を持たせるかは各開発組織しだいなのかなと思います。<br>
小さいプロダクトであれば本番環境相当のデータ量の環境はいらないかもしれませんし、大きくなってきてから考えるという整理もできます</p>
<p>また、Featureやフラグ・カナリアリリースでデプロイタイミングとリリースタイミングを分けるなども考え始めると、もっと色々考えないといｋません。<br>
この辺りは自分もまだまだ勉強すべき箇所です</p>
<h2 id="%E7%90%86%E6%83%B3%E3%81%AEci%2Fcd%E3%81%A8%E3%81%AF">
<a class="header-anchor-link" href="#%E7%90%86%E6%83%B3%E3%81%AEci%2Fcd%E3%81%A8%E3%81%AF" aria-hidden="true"></a> 理想のCI/CDとは</h2>
<p>成熟したCI/CDまで考えたかったのですが、アドベントカレンダーで時間がないのでキーワードだけ</p>
<p><a href="https://cloud.google.com/blog/ja/products/gcp/using-the-four-keys-to-measure-your-devops-performance" target="_blank" rel="nofollow noopener noreferrer">Four Keys</a>がEliteやHighまで実現できていれば、だいだいはCI/CDも成熟しているのではないかと最近思っております！</p>
<h2 id="%E3%81%A9%E3%81%86%E5%B0%8E%E5%85%A5%E3%81%97%E3%81%A6%E3%81%8F%E3%82%93%E3%82%84%EF%BC%9F">
<a class="header-anchor-link" href="#%E3%81%A9%E3%81%86%E5%B0%8E%E5%85%A5%E3%81%97%E3%81%A6%E3%81%8F%E3%82%93%E3%82%84%EF%BC%9F" aria-hidden="true"></a> どう導入してくんや？</h2>
<p>でも、今のプロジェクトではCI/CDをできとらへんわ...という人もいるかもしれません</p>
<p>その時は、現状の把握をして、一番成果が出そうな箇所、例えば複雑なデプロイフローを整理して仕組み化するなどを行い少しづつやっていくのがいいのではないかと私は考えています！</p>
<p>これは何事にもいえることですが、改善するためには現状の把握と計測、改善後の結果確認と振り返りが必須です！<br>
そのための現状把握です！</p>
<h2 id="%E3%81%BE%E3%81%A8%E3%82%81">
<a class="header-anchor-link" href="#%E3%81%BE%E3%81%A8%E3%82%81" aria-hidden="true"></a> まとめ</h2>
<p><strong>変更しやすい＝開発しやすい＝生産性向上</strong> だと最近は考えるようになったので、それに必要なCI/CDについてまとめてみました</p>
<p><strong>変更しやすい</strong> ということは <strong>プロダクトにおける開発の心理的安全性</strong> が担保されているということなのかな？とふと思いました。<br>
自分の気持ちや意見を表明する＝ソースコードを変更する　という風に捉えれば同じ感じなのかな</p>


コンテナCI/CDについて考えてみた

Continuous Integration（継続的インテグレーション）とは？

Continuous Deployment/Delivery（継続的デプロイメント/デリバリー）とは？

Discussion