Webアプリケーションの開発を始めてしばらく経つと、多くのことが日常的に繰り返されるようになっていることに気づくでしょう。技術的なプロジェクト管理、ファイルのバージョン管理、自動コードレビュー、さまざまなデータ処理、あるいはサーバーへのデプロイやセキュリティ関連など、非常に多くのことが行われています。
企業でコンサルティングをしていると、予防が非常に軽視されているという問題にぶつかることが非常に多いのです。その理由は、開発者があることを非常に困難なことだと認識し、それが自分たちの仕事を増やすことになると考えるからであることが多いのです。しかし、実際には、通常、すべてのセットアップを一度設定するだけで、あとは長期的な利益を享受するだけなのです。
CI/CDは、プロジェクトで繰り返される、似たような基盤の定型作業を自動化することができるツールである。CIは、自動テストの実行、コードレビュー、自動デプロイ(アプリケーションをWebサーバーにデプロイすること)、プロジェクト管理、あるいはセキュリティ監査などによく使われます。
CIは、あらかじめ定義されたコマンドをTerminalに対して実行したり、特定のプログラムを実行したりする仮想的なオペレーティングシステムだと考えてください。CIの出力は、成功か失敗かのどちらかで、プロジェクトに直接表示されるだけでなく、管理者にも送られ、対応することができる。特定のイベント(例えば、リポジトリへのコミット、マージ要求/プル要求の受信、タグ/バージョン/リリース、cronのタイムループの実行など)の後にCIジョブを実行するのが良い方法です。
CIの基本は設定ファイルであり、そこで動作やイベントへの対応を定義する。GitHubの場合、ヘルパーディレクトリ .github/workflows
を作成し、その中に .yml
という拡張子を持つ任意のファイルを作成するだけでよいのです。GitHub はコミットごとにこれを解析し、必要に応じて実行します。
特定のタスクを持つ新しい設定ファイルを定義したい場合を考えてみましょう。これはGitHubや仮想マシン上の別の環境から直接実行されるタスクなので、以下のように環境に関する基本的なことを定義しておく必要があります。
仕事の場合は、さらに定義します。
上記のコンテナは、すでに プロジェクトの完全なドッカー化 のための最初の準備です。CIの基本的な使い方は比較的簡単で、Dockerを全く理解していなくても、Terminalのコマンドさえ知っていれば大丈夫です。
タスクの具体的な手順の一部として、先ほどインストールしたオペレーティングシステムのインストールを構築するための個々のコマンドを実行する必要があります。つまり、PHPの場合、PHP言語だけをインストールし(バージョンも指定)、プロジェクトのリポジトリをランナーにクローンし、プロジェクトの依存関係(多くの場合Composer)をインストールし、テスト自体を実行することが重要でしょう。
IT業界では、マイクロソフトは低品質なものを作る悪の企業だという迷信があります。しかし、GitHub Actionsの場合、それは全く当てはまりません。なぜなら、彼らは客観的に見て、世界最高のCIプラットフォームを持っているからです。
GitHub CIの基本的な利点は、記法がシンプルでエレガントなことです。予備知識がなくても、わずか数行で独自のテスト環境を構築し、自動的に管理することができます。同時に、特定のタスクの処理速度が速いことも大きなメリットだと考えています。例えば、codestyle(コードの書式設定)とPhpStan(データ型、ロジック、一般的な正しさのチェック)に関するテストは、通常のプロジェクトではGitHub Actionsで50秒以内に評価できますが、例えばGitLabでは同じテストをほぼ8分かけて評価しています。Travisのような他のソリューションは比較的高価で、ほとんどの開発者は、とにかくその特殊な機能の利点を理解していません。
GitHubには、すぐに使える既成のアクションやパッケージのデータベースが豊富にあります。これらは通常、オペレーティングシステム、プログラミング言語、またはコミュニティからのライブラリです。
マーケットプレイス](https://github.com/marketplace?type=actions)でアクションのデータベースを見つけることができます。例えば、私のお気に入りのアクションはSend SMS in case of failure via Twillioです。
非常に多くの例私は自分のリポジトリで公開していますでは、私がどのような特定の設定を使用しているかを透過的に見ることができます。
例えば、2021年2月のプロジェクトでは、この構成をコードスタイルのチェックに使いました。
name: Coding Styleon:push:branches:- masterpull_request:types: [ assigned, opened, synchronize, reopened ]schedule:- cron: '1 * * * *'jobs:nette_cc:name: Nette Code Checkerruns-on: ubuntu-lateststeps:- uses: actions/checkout@v2- uses: shivammathur/setup-php@v2with:php-version: 7.4coverage: none- run: composer create-project nette/code-checker temp/code-checker ^3 --no-progress- run: php temp/code-checker/code-checker --strict-types --no-progressnette_cs:name: Nette Coding Standardruns-on: ubuntu-lateststeps:- uses: actions/checkout@v2- uses: shivammathur/setup-php@v2with:php-version: 8.0coverage: none- run: composer create-project nette/coding-standard temp/coding-standard ^3 --no-progress --ignore-platform-reqs- run: php temp/coding-standard/ecs check src
この設定ファイルは、最新の Ubuntu (runs-on: ubuntu-latest
) をインストールし、プロジェクトのリポジトリをクローンし (uses: actions/checkout@v2
)、 PHP (uses: shivammathur/setup-php@v2
) バージョン 7.4 をインストールし (php-version: 7.4
) Code-checker パッケージをインストールして PHP で仕事を走らせます。
経験の浅いユーザーのために、もう少しだけ注意点を説明します。
php file.php
コマンド)として実行すると、実行され、その権限でできること(ファイルの操作、インターネット上での通信、画面への出力、...)がすべてできるようになるのです。require-dev
ファイルの composer.json
セクションに置いて、特定のプロジェクトで必須の依存関係としてインストールされないようにします。他のリポジトリホストとは異なり、GitHubはいわゆるGitHub Appsと自動化ボットをサポートしています。これは、あなたのプロジェクトで(CIなしでも)自動操作を実行できる既製のボットの大規模なデータベースで、彼らが何かに遭遇したとき、例えば、問題をファイルしたり、修正したプルリクエストを送信したりします。
個人的にも使っていて、おすすめです。
その他、多くのアプリケーションはマーケットプレイスで見ることができます。
私はGitHubの自動化タスクを使うのが非常に好きになりました。
私はすべてのリポジトリで自動チェックを設定しており、私がコミットを送信すると(あるいはコミュニティの他の誰かが)、コードの品質(codestyleとPhpStan)、セキュリティなどが侵害されていないかどうか、リアルタイムでフィードバックを得ることができます。
1時間ごとに自動で実行されるテストがあるのですが。例えば、セキュリティ上の脆弱性やCVEがあった場合、具体的に何が起こったのか、具体的なプロジェクトのレベルでも遅くとも1時間以内には知ることができるのです。
長い間、さまざまな構成をテストしてきた結果、私は以下のようなComposerへの依存関係を理想的な最小セットアップと考えるに至りました。
tracy/tracy
- 高レベルのエラー報告とロギングphpstan/phpstan-nette
- Nette における Phpstan の拡張機能と特化した機能spaze/phpstan-disallowed-calls
- Michal Spacek による、コード中の危険なもの (忘れられた変数ダンプからシェルコマンドとしてユーザ文字列を実行する機能まで) の (誤った) 使用を処理する素晴らしいライブラリです。roave/security-advisories
- 安全でないバージョンのパッケージのインストールをチェックします (特定のパッケージにセキュリティ脆弱性が見つかったり、CVE がリリースされた場合、このパッケージは破損したバージョンのインストールを防止します)基本的なセキュリティの設定は、少なくとも8時間ごとに自動実行され、エラーがメールに送られるように設定するのが理想的です。なぜなら、プロジェクトのインストールに失敗したり、新しい脆弱性が発見されたりするたびに、できるだけ早くそれを知って、すぐに対応したいからです。
すべて自動で動くので、セキュリティチェックなどの複雑な処理をしたとしても、余計な手間はかからず、初期設定さえしっかりしていれば、いつでも安心して利用できることを忘れないでください。
なぜなら、予防と自動化には大きな可能性があるからです
Jan Barášek Více o autorovi
Autor článku pracuje jako seniorní vývojář a software architekt v Praze. Navrhuje a spravuje velké webové aplikace, které znáte a používáte. Od roku 2009 nabral bohaté zkušenosti, které tímto webem předává dál.
Rád vám pomůžu:
Články píše Jan Barášek © 2009-2024 | Kontakt | Mapa webu
Status | Aktualizováno: ... | ja