GitHubアクションを学ぶ

序文

継続的インテグレーション／継続的デリバリ（CI/CD）の基本概念は、ThoughtworksのMartin FowlerとMatthew Foemmelが2000年9月に発表したエッセイでCIを初めて世に広めて以来、数十年前から存在している：Build, Test, and Deployment Automation Through Reliable Software Releases』（Addison-Wesley Professional）でCDについて書いている。しかし、CI/CDのためのツールが広く採用され、ソフトウェアデリバリパイプラインという概念が定着するまでには、何年もかかった。これは、ソフトウェア開発のやり方において、3つの根本的な社会技術的変化が最初に起こらなければならなかったからだと私は考えている：

• 開発は、孤立した個々のエンジニアが行うのではなく、共同作業となる必要があった。これはまず真の分散バージョン管理システム（Git）によって推進され、GitHubのようなプルリクエスト・プラットフォームによって加速された。
• アジャイルプラクティスを広く採用する必要があった。DevOps Research Associates (DORA)のようなDevOpsリーダーから、直感に反して、より小さな変更の継続的なデリバリがリスクを低減することを示すメトリックに動かされ、賢明なエンジニアリングリーダーは、ソフトウェアを継続的にビルドし、テストし、時には1日に何十回も顧客に直接デプロイする、頻繁に使用されるビルドパイプラインの実装を推進した。
• 従来のIT運用関数が複雑化し、過重な負担を強いられるようになったことで、DevOpsムーブメントを通じた大規模な文化的変革が推進された。そこでは、ビルド・プロセスを運用するリリース・エンジニアリング・チームにコードを丸投げしたり、まだ品質が備わっていないソフトウェアにどうにかして「品質を追加」したりするのではなく、開発者が本番でのソフトウェアの成功、失敗、パフォーマンスに対して完全なオーナーシップを持つようになっている。

これらの変化は、GitHub ActionsがCI/CDパイプラインと自動化のカテゴリーに比較的最近参入した製品であり、既存の製品とは大きく異なることを意味する。GitHub ActionsはGitHubにネイティブに統合されており、ソースコードをGitHubに保存することに慣れ親しんでいる開発者には自然にフィットする。GitHub Actionsはまた、ワークフローという概念に基づいて設計されており、CI/CDパイプラインの作成だけでなく、オープン・イシューの管理や、オープン・ソースやエンタープライズ・デベロッパーがワークの過程で行う必要のあるタスクなど、あらゆる種類のソフトウェア自動化タスクに対応することができる。最後に、GitHub Actionsは、その名前からもわかるように、アクションという概念に基づいている。アクションは再利用可能なコンポーネントであり、ワークフローを作成する際に共通のタスクをカプセル化し、繰り返しを減らすのに役立つ。GitHub Marketplaceでは、本稿執筆時点で約20,000のアクションが提供されており、開発者やDevOpsエンジニア、サイトの信頼性エンジニアがあらゆる種類のビルド自動化タスクを簡単に開始できるようになっている。

GitHub Actionsは洗練された製品だが、それを学ぶのに複雑さは必要ない。Brent Laster は、GitHub ...