Actionsの導入を考えてみた(...が、...)。JavaScriptを有効にして再度、お越しください。Actionsの導入を考えてみた(...が、...)。Actionsの使い方については全く言及していません。Actionsのv2が来月辺りにGAされる。言う事で、にわかな盛り上がりを感じたりし、以下の様にチョット調査をしてみました。Actionsで出来る事、ビルド自動化までかなぁ。」と思いつつ、「ソレ、現行のバッチで間に合ってるンだケド。」みたいなループを、また、してしまいました(コレ、一体、何回目だろうか...?)。私が思うに、方法論やツールから入る場合、これらは汎化され過ぎて、スッカスカになっている状態なので、それを、ある程度、特定のドメインにハメた上で(、そもそもハマるのか?ハマらないのか?という次元で)、議論しないと、議論にもならない気がします。...と言う事で、CI/CDに関する、議論や評価をするには、開発からビルド・リリースまでやって、かなり内情を解って無いと評価ができないと思います(つまり、並みの人では評価自体が不可能な)ので、なかなか導入は難しいんだと思います。過去にも色々と書いてますが、CIを軽くdisったケド、ライブラリ開発でプラクティスを実践している件。以下に列挙してみようと思います。私のドメインの場合まとめ<ライブラリの場合>ライブラリの場合は、まぁ、出来そうだけど、私、そもそも、テスティング・フレームワーク自体を使ってないんですよね(面倒臭いんですよねアレ)。その出力をGitで管理しているんですよね。commitして、以降、変更があった場合に、出力をDiffで確認し、変更があったら、それに問題が無いか?を個別に確認する感じです。全資産分の単体テスト相当のテストコードを書いて無いんですよね(実は書く気もあまり無い。ペイラインが高く、優先度も低いため)。オンデマンドのテストはしますが、Actionに対応した機械的なテストと言うのは殆どしません。pushなどのActionでCI/CDするというモチベーションは、今の所、殆どありません。<アプリケーションの場合>アプリケーションの場合は、RDBMSがあるので、これがハードルですね。GUIもあったりするので、コレをテストするのは、結局のトコロ容易ではありません。パイプライン上でやる必要あるか?というのが私のプロジェクトの場合の見解です。Cloneして、ビルド・デプロイするスクリプトを実行し、疎通的なレグレッションを行えばイイのでは?と思います。こちらのタイミングも、SI状況によってオンデマンドのテストはしますが、Actionに対応した機械的なテストと言うのは殆どしないと思います。他のリポジトリからは、Templateリポジトリを、ダウンロードZIPローカル・ビルドビルド出力をDLL参照する。いう処理を全部、BATとPowerShellで自動化済みで、起動はオンデマンド。pushで起動などの要件が無い。Actionsは、今の所、ハマりませんでした。Composeを使用して、Webサービスとそのデータベースの両方を起動して疎通テストを実行する。実装出来れば、先ずは「あったらイイね。」(必須じゃないケド)と言えるのかもしれません。ベストプラクティスは無い。」と言うのが「まとめ」だ。あなたのドメインでは何が必要とされているのか?を、方法論のレベルで議論を開始するのが最も重要で、始めからツールやプラットフォームにフォーカスして、如何にソレ等を自ドメインにハメるか?とするとホント、全然ダメになる印象です(と言うか、"中途半端な提案をされると、逆に迷惑になる。CDの方法論は、ツール類が整備される前に大枠が確立されている訳なので、特に、ステージング環境にデプロイして疎通テストするようなケースでは、専門的なツールは、あまり重要では無いですよね。以下、余談ですが、前述したように、汎化された情報って、直接的には役に立たないので(参考)、継続させるためには、オープンにして行く方が良い気がします。...と言うのも、生産性向上に関する以下の様なブログもあるらしく、この粒度のアウトプットとしては、既に組織内より組織外の方があてになる時代になって来ている感があるので。生産性向上ブログhttps://www.kaizenprogrammer.com/entry/2019/08/18/205010故に、組織内でやることと、組織外でやることを、ソロソロ、本気で分けて考えてイイ時代になって来たと思います。