「うちの開発チームにもイケてるCI/CDパイプラインを導入したいんだけど作ってくれる?」
突然こんな依頼が舞い降りた時、あなたは対応できるでしょうか。
逆にどんなスキルがあればこのような無茶ぶり依頼に対応することができるのでしょうか。
自分自身の経験の振り返りと整理も兼ねて、CI/CDエンジニアに求められるスキルを挙げてみます。
前提
- 基本的にはアプリケーションのCI/CDを想定して書いています。
- CI/CDツールの設定をするだけの人ではなく、CI/CDパイプラインをがっつり設計する人に求められるスキルを想定して書いています。
必要なスキル
開発プロセス設計
いきなり曖昧で広い言葉ですいません。
しかし、CI/CDは開発プロセスと密接に関連していて切っても切れない関係です。
どこにあるソースのどのブランチをビルドして、どういうルールでタグ付けして、どこにデプロイして・・・と考えることはたくさんあります。
そもそもCI/CD以前の話としてちゃんとしておかなければいけない部分ですが、今から頑張ってCI/CDを導入しようなんてところではこの辺が適当なケースもままあります。
わかりやすいところではGitのブランチ戦略やタグの使い方を考えることになりますが、開発チームが効率よく、気持ちよく開発を進めるためにはどうすればいいかというのをCI/CDを含めて考えることができると最高です。
具体的に何を身につけておけばという項目は挙げづらいですが、チーム開発の基礎、Gitフローなどの開発フローの知識、バージョン管理の知識などが必要になるでしょう。
ビルド
CI/CDで必須の処理がビルドです。
開発チームがしっかりしていれば何かしらのビルドツールが導入されていて、いくつかのコマンドを実行するだけビルドできるでしょう。
しかし、開発メンバーのPC上で動いていたものがCI/CDの実行環境上でそのまま素直に動くとは限りません。
大抵は何かしらのエラーが発生するので、うまくデバッグしながら動くようにする必要があります。
これにはビルドで実行されている処理内容の理解だけでなく、ビルドツール自体の処理内容も把握しておく必要があります。
また、設定値やコマンドの実行オプションが関連する場合があるのでそういった細部の知識もあるとよいです。
経験上よくあるのは、ビルドツールのバージョンが違うとか通信設定に差異があってパッケージリポジトリにアクセスできないとかしょうもないことが多いですが、はまるとなかなか解決できず時間が溶けてしまいます。
テスト
ビルドと並んでテストも重要な処理になります。
xUnitのような単体テストを実行するだけの場合もあれば、UIテストの自動実行をしたい場合もあるでしょう。
単体テストは普段IDEから実行することが多いと思いますが、CI/CDのためにはコマンドラインでの実行方法を把握しておきましょう。
UIテストに関しては、ディスプレイのないサーバ上で同実行するかを考える必要があります。ほとんどのケースではヘッドレスブラウザを使ってコマンドラインから実行すると思うので、関連する知識が必要です。
テストの実行時間というのはパイプライン上でボトルネックになりがちなので、後述のコンテナ技術などと組み合わせて並列化することも視野に入れましょう。
また、テストの作り方の注意になりますが、実行するたびに結果が変わるようなテスト (flaky test)を作らないことが重要です。
これによって、CI/CDの成否が実行するたびに変わるという状況が発生してしまいます。
こうなると、パイプラインが失敗していてもエンジニアがあまり気に留めなくなってしまうので非常によくないです。
どうしてもflaky testが存在する場合は、それだけCI/CD上での処理を分けるなどの工夫が必要です。
静的検査
ここでいう静的検査とはLint系のツールを考えて頂ければよいです。
CI/CDを活用して品質を高めていくためには静的検査ツールの導入は非常に効果的です。
静的検査ツールはだいたいの言語にはデファクトと呼ばれるようなツールが存在するので選ぶのはあまり難しくありませんが、どのようなルールセットで検査するかを考える必要があります。
公開されているルールセットをそのまま使うというのでも簡単にそれなりの効果を得ることができますが、チームやプロダクトの特徴に適したものを用意するとさらに効果的です。
静的検査の結果においても、常時何かしらの指摘が発生しているという状態はよくありません。
不要なルールはルールセットから取り除く、誤指摘やどうしても対応できない指摘などやむをえず残るものもその旨をきちんと記録しましょう。検査ツール自体に指摘の無視や解決済みへ変更などの設定があれば活用しましょう。
こういった細部の運用をしっかりと詰めることも理想的なCI/CDパイプラインの構築には不可欠です。
開発環境設計
これもやや広い言葉になりますが、CI/CDに関連する開発環境を設計する能力が必要です。
構成要素としては開発PC、CI/CDサーバ、ソースコード管理サーバ、ライブラリ管理サーバ、コミュニケーションツール(チャットなど)、テスト環境、本番環境などでしょうか。
自分たちが求めるCI/CDパイプラインにおいて、これらの構成要素がどうなっている必要があるのか、要件を整理して設計できる必要があります。
特にCI/CDツールと各種ツールの連携方法は押さえておく必要があります。
メジャーなツール同士であればプラグインなどで比較的用に連携が実現できますが、ものによっては自前でスクリプトを組んでAPIを叩いたりすることになります。
単にAPIを叩くといっても、API経由での認証方法を調べて、レスポンスの仕様を調べてパースしてとやっていくと意外と時間がかかってしまいます。
ここは慣れの領域なのでたくさん経験するのが一番ですが、得意なスクリプト言語が1つあるといいでしょう。
CI/CD的にはなるべくOSの初期状態で実行環境が整っているものだとよいです。
コンテナ技術
コンテナ技術(≒Docker)は今はCI/CDとは切り離せない存在です。
必要な時に必要な分のクリーンな環境を立ち上げて終わったら破棄できるというのはCI/CDと非常に相性がよいです。
コンテナをパイプラインに組み込むにあたっては、コンテナの基本的な知識はもちろんのこと、必要なツールをインストールしたコンテナイメージを自作できる必要があります。
パイプラインのパフォーマンス改善を考えるとコンテナイメージの軽量化も外せません。
また、そもそもCI/CDの成果物がアプリケーションを埋め込んだコンテナイメージということも珍しくないので、コンテナ関連の知識はCI/CDの観点からも必須です。
パブリッククラウド
パブリッククラウドも昨今の開発では非常に重要な位置を占めています。
オンデマンドで必要なリソースを要求できるので、処理の実行時のみにリソースが必要なCI/CDにとっては大きなメリットがあります。
また、主要なパブリッククラウドにはCI/CDやDevOpsを支援するサービスが存在しており、高速に環境を立ち上げることができるというのも強いです。
全部をパブリッククラウド上で実現するとなれば、オンプレミス環境やSaaSのCI/CDを使う場合とはまた違った観点で物事を考える必要があります。
そういう意味でクラウドに適した開発環境とそれに付随するCI/CDを設計できるスキルが必要です。
CI/CDツール
CI/CDを実現するためのツールですが、網羅するのが難しいぐらいたくさんあります。
有名どころとしては、Jenkins、GitLab CI、Circle CI、Travis CIなどでしょうか。
他にもDrone.IO、GoCD、Spinnaker、Concourse、CodeShip、Tektonなどもあります。
各ツールで得意/不得意はありますが、ある程度のことはどのツールでもできる(はず)なので、自分として詳しいといえるツールを1つは持っておきましょう。
よほど余力がなければ実績が少ないツールをいきなり採用というのも難しいと思うので、有名どころを使うケースが多いかなと思います。
まとめ
世の中には「いけてるCI/CDパイプライン作ったぜ」的な情報があふれているので、ともすれば簡単にできるものと思われがちです。
しかし、CI/CDをしっかり作りこむことは開発プロセスを定義することに近いので、それ相応の広い知識が求められます。
今回はアプリケーション関連の話を主に書きましたが、インフラに近い話を始めるとさらにたくさんでてくると思います。
でもCI/CDパイプラインの構築って、いろいろ自動で流れるようになっていく様子が楽しいんですよね。
CI/CD関連のお仕事をされている皆様、精進しながら楽しみましょう。