CI/CDのためのツールを使うと、プラットフォームごとに固有のワークフローの指定を書いていくことがある。
- GitHub Actionsを使ってCI/CDパイプラインをつくると、stepsに1工程ずつの処理を書いていくことになる
- AWS CodeBuildを使ってCI/CDパイプラインをつくると、commandsに1工程ずつの処理を書いていくことになる
- Jenkinsを使っていると、XMLを書いたり、Groovyのスクリプトに書くことになる
うちのチームでは以上3つを同時に使っていて、場所によってさまざまなツールが使われている。どこかに揃えたいという気持ちはあるけど、微妙に要件が違ったりする。
ところで、手元の開発で同じような構成を取りたいとき、たとえば、CIで動かすDockerイメージと手元開発のDockerイメージを揃えたいとき、などは、script/setup.sh とか、scrpt/docker-build-and-push.sh みたいな、手元開発用のスクリプトは別途用意することになる。
そこで気になるのが、どこまでプラットフォームごとに寄り添っていくかということ。
- プラットフォームに寄り添っていくと、どこで止まったのか、どこまで進んだのかを1ステップずつプラットフォームのUI上で見れるほうが便利なので、プラットフォームごとのYAMLやXMLに寄っていく
- 手元の開発や、どこでも同じように動くこと、に寄り添っていくと、手元で動くほうが便利なので、単一のシェルスクリプトなどに寄っていく
うまくいっていない場合を考えると、CI上で巨大シェルスクリプトが動いていてどこで止まったかわからない、とか、逆に、CI上で止まることは分かったけどて元で再現できない、といったことが考えられる。
追加で考えるべきこととしては、どこまで再利用性を求めるかということ。
シェルスクリプトなら自由に実行できるけど、1 workflowが1 YAMLと対応している場合があって、再利用性が低かったりする。
このあたり悩みながら進めていて明確な基準を見いだせていない。
みなさまはどのようにバランスを取られていますか。
