あの頃の私に「CI/CD パイプライン作ってみな、スキルあがるよ」と言いたい

この記事はNTTコムウェア AdventCalendar 2024 11日目の記事です。

はじめに

NTT コムウェアの金子です。RHEL¹系のサーバ構築を自動化する業務に従事しています。
今でこそ自動化推進の業務に従事してますが、新人時代はアサインされた業務を淡々とこなす日々でした。
Microsoft Office (Word、Excel、PowerPoint など) を使用して、設計書や試験項目表を作成する日々を送っている新人時代の私へ。
バージョン管理システムで Microsoft Office ファイルを管理してみたものの使いづらさを感じ、愚痴をこぼしている新人時代の私へ。
そんな新人時代の私に「ツールのポテンシャル全然活かせてないよ」と伝えてあげたく思います。

バージョン管理システムは CI/CD パイプラインの起点となるファイルを管理してこそ真価を発揮するもの

「バージョン管理」とは「いつ、だれが、どのような変更を加えたのか」を管理することです。
バージョン管理システムを導入している開発現場では、例えば次のようなことが可能です。

• バージョン間の差分を確認する
• 他の人が変更した内容をマージする
• 問題の原因がいつ混入したのかを追跡する
• ファイルを以前のバージョンに戻す

一般的なバージョン管理システムが、特別なカスタマイズなく適切に取り扱うことができるファイルはテキストファイルです。
Microsoft Office ファイルなどのバイナリファイルは、一般的なバージョン管理システムで管理するファイルとしては不向きです。一般的なバージョン管理システムでは、特別なカスタマイズなく、バイナリファイルのバージョン間で意味のある差分情報を出力することはできず、他の人が変更した内容をマージしたりするとファイルが破損してしまいます。

バージョン管理されるテキストファイルには、例えば次のようなものがあります。

• ソースコード
• 設定ファイル

上記は後述する「CI/CD² パイプライン」の起点となるファイルです。
バージョン管理システムは「バージョン管理」のみを目的として導入するだけでも強力なツールになりますが、 CI/CD パイプラインの起点となるファイルを管理することでその真価を発揮します。

GitHub はお手本の宝庫であり、つよつよエンジニアとの接点になるもの、Git は仕方なく使っていれば使えるようになっているもの

最も広く使用されているバージョン管理システムの一つに Git があります。
そのシェアの多さから複数の Git ホスティングサービスが提供されています。
Git ホスティングサービスの代表格が GitHub です。

GitHub には、つよつよエンジニア が書いたドキュメントやソースコードがたくさんあります。
それらを読みながら、ぜひとも自動化を進めてみましょう。
自動化にあたっては、基盤からアプリケーションまで、すべてをコード化することができないか、を考えましょう。
基盤をコードで表現することを Infrastructure as Code といいます。
"何か"を自動化するには、自動化に関する知識だけでなく、その"何か"の知識が必要になります。
必ずしもすべての自動化をあなたが実施する必要はありませんが、フルスタックに挑戦した経験はエンジニアとしてのあなたの価値を高めることでしょう。

あるプロダクトに何らかの問題を見つけたら、ぜひともコミュニティに貢献してみてください。
問題を報告したり、プルリク³を作成したりすることは、あなたが つよつよエンジニア になるための第一歩になります。
GitHub で管理されているプロダクトの問題を確認・検証し、プルリクを作成するには Git を使わざるを得ないので、この経験を繰り返せば Git が使えるようになることでしょう。実際に使うことが何よりも重要です。

CI/CD パイプラインは自動化で PDCA サイクルを加速させるものだけど、それ以上にあなたの技術的成長を促すもの

Git ホスティングサービスの多くは Git リポジトリを「CI/CD パイプライン」の起点とするための仕組みが提供されています。
例えば GitHub の場合は、 GitHub Actions が該当します。
「CI/CD パイプライン」は「バージョン管理されているファイル」の変更を契機にビルドからテスト、デプロイまでを自動で実行します。
ソースコードに加えた変更を迅速に動作確認できるため、PDCA⁴ サイクルを高速に回すことが可能です。
顧客の要求をエンジニアがソースコードに反映し、リリースされたプロダクトに対するエンドユーザの反応を受けて、顧客が新たな要求をエンジニアに提示する…その一連のサイクルを加速させることが開発プロジェクトでは重要です。
ソースコードを作成できたならば、ぜひとも CI/CD パイプライン構築に挑戦してみてください。
バージョン管理システムで Microsoft Office ファイルを管理していただけでは得ることができなかった「自動化のパワー」を感じることができるでしょう。
自動化を成し遂げ、CI/CD パイプライン構築を完了したころには、一連の開発プロセスを自分の手で実践できるだけの技術を身に着けていることでしょう。

CI/CD パイプラインを組織の中で価値あるものにすることがエンジニアとしての腕の見せ所

あなたがソースコードを作成したプロセスは開発フェーズのものですが、組織の中で「CI/CD パイプライン」をより価値あるものにするためには運用フェーズで得られる有益な情報をソースコードにフィードバックする必要があります。
運用フェーズで得られる有益な情報の取得からソースコードへのフィードバックまでのプロセスは、一般的な CI/CD パイプラインの中にはありません。
このプロセスを如何にして実現するかがエンジニアとしての腕の見せ所です。

「運用フェーズで得られる有益な情報」にはどのようなものがあるかを、Web サービスを運用しているケースを例に考えてみます。
サービス提供者としては、例えば、次のような情報が有益なものになりえるでしょう。

• エンドユーザの動線
• エンドユーザの属性(性別、年代など)
• 回遊率
• ABテスト結果
• etc…

システム運用者としては、例えば、次のような情報がが有益なものになりえるでしょう。

• エラー発生有無
• 性能情報(ディスクI/O、ネットワークI/Oなど)
• リソース情報(CPU、メモリ、ディスク使用率など)
• 各種アラート情報(脆弱性対策情報、セキュリティ診断結果、システム監査結果など)
• etc…

顧客は「サービス提供者」として、運用フェーズで得られた情報をもとにサービスを改善、成長させるための新たな要求をエンジニアに提示します。
エンジニアは「システム運用者」として、運用フェーズで得られた情報をもとにシステムの品質を維持、向上させるための改善策を顧客に提案します。
顧客の要求をどのように理解し、顧客に対してどのような提案をし、ソースコードの中にどのように表現するかは、エンジニアの腕にかかっています。

開発フェーズだけでなく、運用フェーズも視野にとらえて、システム開発ライフサイクルの改善(自動化)に取り組むことは、DevOps⁵ の実践にもつながることでしょう。

まとめ

日々の業務に少しずつでも自動化を取り入れ、CI/CD パイプラインを活用することで、業務効率を大幅に向上させることができます。バージョン管理システムによって、コードやドキュメントの変更履歴を明確に管理し、チームでの開発を円滑に進めることができます。
Git や GitHub を利用することで、他のエンジニアとの接点を持ちつつ、自動化の知識を深め、実践を通じて技術を磨いていきましょう。自動化は一見ハードルが高いように思えても、小さなステップから始めれば、必ずあなたの成長につながるのです。失敗を恐れず、挑戦し続けることで、つよつよエンジニア への道を切り開いていくことができるでしょう。

---

記載されている会社名、製品名、サービス名は、各社の商標または登録商標です。

1. RHEL は Red Hat Enterprise Linux の略です。 ↩

2. CI/CD は Continuous Integration (継続的インテグレーション) / Continuous Delivery (継続的デリバリー) の略です。 ↩

3. プルリクは Pull Request の略です。 ↩

4. PDCA とは、Plan (計画)、Do (実行)、Check (評価)、Action (改善) の頭文字を取ったもので、継続的な業務改善を目指す方法です。 ↩

5. DevOps は文化的な基本方針、手法、ツールの組み合わせであり、ソフトウェア開発 (Development) と情報テクノロジーの運用 (Operations) とを結びつけるものの総称です。 ↩