（予め、断っておきますが、この記事、GitHub Actionsの使い方については全く言及していません。）GitHub Actionsのv2が来月辺りにGAされる。と言う事で、にわかな盛り上がりを感じたりし、以下の様にチョット調査をしてみました。

　CI/CD パイプライン - マイクロソフト系技術情報 Wiki

　...が、「GitHub Actionsで出来る事、ビルド自動化までかなぁ。」と思いつつ、「ソレ、現行のバッチで間に合ってるンだケド。」みたいなループを、また、してしまいました（コレ、一体、何回目だろうか...？）。

　私が思うに、方法論やツールから入る場合、これらは汎化され過ぎて、スッカスカになっている状態なので、それを、ある程度、特定のドメインにハメた上で（、そもそもハマるのか？ハマらないのか？という次元で）、議論しないと、議論にもならない気がします。

　...と言う事で、CI/CDに関する、議論や評価をするには、開発からビルド・リリースまでやって、かなり内情を解って無いと評価ができないと思います（つまり、並みの人では評価自体が不可能な）ので、なかなか導入は難しいんだと思います。

　過去にも色々と書いてますが、


　以下、今回、私が改めて考えたことを、
　以下に列挙してみようと思います。

• ライブラリの場合
• アプリケーションの場合
• 私のドメインの場合
• まとめ

＜ライブラリの場合＞

　ライブラリの場合は、まぁ、出来そうだけど、私、そもそも、テスティング・フレームワーク自体を使ってないんですよね（面倒臭いんですよねアレ）。なので、テストコードを Console.Writeline() して、その出力をGitで管理しているんですよね。新規開発時にオールグリーンの結果をGit commitして、以降、変更があった場合に、出力をDiffで確認し、変更があったら、それに問題が無いか？を個別に確認する感じです。

　また、全資産分の単体テスト相当のテストコードを書いて無いんですよね（実は書く気もあまり無い。何故ならペイラインが高く、優先度も低いため）。なので、オンデマンドのテストはしますが、Actionに対応した機械的なテストと言うのは殆どしません。

　上記のようなプラクティスにしようと考えているので、Git pushなどのActionでCI/CDするというモチベーションは、今の所、殆どありません。

＜アプリケーションの場合＞

　アプリケーションの場合は、RDBMSがあるので、これがハードルですね。また、GUIもあったりするので、コレをテストするのは、結局のトコロ容易ではありません。

　なので、コチラの場合は、CI/CDしたあとに、レグレッション・テスト的なテストを流す的なプラクティスが最も低いハードルになるのだと思いますが、これ、CI/CD パイプライン上でやる必要あるか？というのが私のプロジェクトの場合の見解です。

　そんなツールを使わなくても、SI環境で、Git Cloneして、ビルド・デプロイするスクリプトを実行し、疎通的なレグレッションを行えばイイのでは？と思います。こちらのタイミングも、SI状況によってオンデマンドのテストはしますが、Actionに対応した機械的なテストと言うのは殆どしないと思います。

＜私のドメインの場合＞

　私のドメインでは、

• 本体リポジトリでNuGetパッケージを生成・登録して、
• TemplateリポジトリでNuGetパッケージを参照して、
• 他のリポジトリからは、Templateリポジトリを、
• ダウンロードZIP
• ローカル・ビルド
• ビルド出力をDLL参照する。

　という処理を全部、BATとPowerShellで自動化済みで、起動はオンデマンド。pushで起動などの要件が無い。と言う事で、GitHub Actionsは、今の所、ハマりませんでした。

　ただ、以下を見ると、Docker Composeをが使えるらしいので、


　テスト専用リポジトリを新設して、テスト・アプリケーションを準備、Docker Composeを使用して、Webサービスとそのデータベースの両方を起動して疎通テストを実行する。位がサクっと実装出来れば、先ずは「あったらイイね。」（必須じゃないケド）と言えるのかもしれません。

＜まとめ＞

　ある意味、「CI/CDパイプライン に ベストプラクティスは無い。」と言うのが「まとめ」だ。と言う気がしています。

　あなたのドメインでは何が必要とされているのか？を、方法論のレベルで議論を開始するのが最も重要で、始めからツールやプラットフォームにフォーカスして、如何にソレ等を自ドメインにハメるか？とするとホント、全然ダメになる印象です（と言うか、"中途半端な提案をされると、逆に迷惑になる。"と言うレベル）。

　コレについて、もう少し根拠を補足すると、CI / CDの方法論は、ツール類が整備される前に大枠が確立されている訳なので、特に、ステージング環境にデプロイして疎通テストするようなケースでは、専門的なツールは、あまり重要では無いですよね。

---

　以下、余談ですが、前述したように、汎化された情報って、直接的には役に立たないので（参考）、継続させるためには、オープンにして行く方が良い気がします。

　...と言うのも、生産性向上に関する以下の様なブログもあるらしく、この粒度のアウトプットとしては、既に組織内より組織外の方があてになる時代になって来ている感があるので。


　故に、組織内でやることと、組織外でやることを、ソロソロ、本気で分けて考えてイイ時代になって来たと思います。