はじめに
記載情報は CI/CD について、となります。
実務では利用環境が変化し続けるため、何もせずに次の環境へと移ると完全に忘れてしまうので備忘録にしたい気持ちも大きいです。
興味のある CI/CD 環境を単純化して手元で動くようにしていきます。
詳細な情報は先人のお知恵を拝借しつつ、「動かすまでには実際なにしてるの？」の部分を投稿できればと思っています。
これまで関わった環境・機能にて「hello world」を出しながら連携させていくイメージで進める予定です。
各学習上、お金のかからない方法を選択していきます。
対象者と関連環境・機能
この記事は下記のような人を対象にしています。
- CI/CD 初学者
- プログラミング初学者
- 駆け出しエンジニア
この後、記載を予定している環境・機能は以下です。
- Spring Boot
- Spring Web
- Gradle
- Azure Devops
- Azure Artifacts
- Azure Pipelines
- Linux (Ubuntu, Red Hat Enterprise Linux)
- Docker
- Kubernetes (minikube)
- OpenShift (minishift)
- Ansible
CI/CD とは?
引用元：CI/CD とは
「CI/CD」とは、ソフトウェア開発におけるビルドやテスト・デリバリー・デプロイメントを自動化し、継続的に行うアプローチを指す名称です。
「CI」と「CD」はそれぞれ「Continuous Integration（継続的インテグレーション）」と「Continuous Delivery（継続的デリバリー）」の略で、この 2 つを組み合わせて「CI/CD」と呼んでいます。
出典：NIF CLOUD
開発者の立ち位置、パイプライン挙動が直観的に分かりやすい情報につき引用させて頂きました。
さらに「実際のところは？」を簡易的に付け加えるとすると以下のようなものがあがるかと考えました。
実際のところは？
数名で作って各々検証してすぐリリース、という規模の場合には「やりやすさ」に重点をおいて進められれば良いと思います。
しかしながら、組織が大きくなると環境の複雑さは段違いです。
下表は目にしたプロジェクトの工程を単純化した例です。
１つのプロジェクトで必要な工程と作業の例
| No | 工程 | バージョン管理 | 成果物管理 | 単体試験 | ビルド | リリース |
|---|---|---|---|---|---|---|
| 1 | ライブラリ開発 | 〇 | 〇 | 〇 | 〇 | |
| 2 | アプリ開発 | 〇 | 〇 | 〇 | 〇 | |
| 3 | 結合検証 | 〇 | 〇 | 〇 | 〇 | |
| 4 | 性能対策 | 〇 | 〇 | 〇 | 〇 | |
| 5 | 運用シナリオ検証 | 〇 | 〇 | 〇 | 〇 | |
| 6 | 本番リリース | 〇 | 〇 |
さらにプロジェクトによって、以下の特徴も見受けられました。
- 工程は上記以上に細分化され複雑
- 一つのプロジェクトの中で各工程が並行して進む
- 多数のプロジェクトが並行して進む
- 最終的に各プロジェクトが一つに合流する
それぞれのプロジェクトでブランチ戦略があり、直接開発を行っていない検証チーム、運用チームも理解可能な環境になっている必要もあります。
こうなると「全部手作業でバージョン管理してリリースしておいてね、ミスしちゃだめだよ」と言われても、いつ何人必要になるか試算するだけで結構な時間がかかりそうです。
ここで、諸々自動化可能な CI/CD がこの解決策の一つとして上がってくる形となります。
一番楽できそうな（コストが下がりそうな）方法抽出判断
本記事では「こんなこといちいち手順みながらサーバ上でシェル叩くのか？」といったあたりについての解消の一助になれば、といった意図でのご紹介とさせていただきます。
最終的に「Azure-Pipelines がベストな方法か？」といえば、必ずしもそうではないです。
利用までのハードルが低めで助かる印象もありますが、Azure-Pipelines 固有のタスク挙動に振り回された挙句、別ツールでの自動化案も出るような場合、結局各タスクはシェルスクリプトとして別に切り出しておいた方が汎用性はあります。（ログ出力とかも自前で工夫する形と思いますが、そこ含めて何が自環境にあっているか、の判断になると思います。）
自動化の方法が複数ある中で、一番楽できそうな（コストが下がりそうな）方法抽出判断の参考になっていたら幸いです。
| 対象 | 判断 |
|---|---|
| 横展開、量産の有無 | 対応の必要があり次第、対応のしやすさがコストに直結 |
| 作業者の手間 | 開発者には開発に注力してもらう必要があるので、即座に、繰り返し実行しやすいことが重要 |
| 運用側の手間 | 開発側に作業環境連携して手順送って、使い方について問い合わせもまあまあ来る、という事態を避けられそうか |
関連作業
- CI/CD とは?
- Azure Devops (Artifacts) を無償、無料で使う
- Spring Tool Suite 4 インストール、Spring Initializr 、gradlew の利用
- Spring Boot Web アプリケーションを作る
- Jar の Library を作り、Azure Artifacts を利用して成果物を配布する
- ライブラリ開発者より指定されたバージョンを利用してアプリを作る
- アプリを Docker 、Docker Compose でコンテナを動かしてみる
- Azure Devops (PileLines) を無償、無料で使う
- Azure Devops (PileLines) でテスト、ビルド、イメージプッシュをする
- minikube(kubernetes) でコンテナを動かしてみる
- nginx のコンテナを Docker や minikube(kubernetes) で動かし、静的コンテンツ公開工程を模倣