インタープリター言語にCIを使用するにはどうすればよいですか？

これまでに継続的インテグレーションシステム（CI）を使用したことがありません。私は主にMATLAB、PythonまたはPHPでコーディングします。これらのどちらにもビルドステップがなく、CIがどのように作業に使用できるかわかりません。大企業の大規模プロジェクトの友人から、言葉は関係ないと言われました。

ビルドステップがない場合、CIがどのように役立つかわかりません。CIは、単体テストを実行するテスト環境と考えることができます。何か不足していますか？

用語としての継続的統合は、2つの異なるアイデアを指します。

1つ目はワークフローです。チームの全員が自分のブランチで作業し、数週間のプログラミングの後、変更をメインラインにマージしようとする代わりに、その変更は（ほぼ）継続的に統合されます。これにより、問題が早期に表面化し、互換性のない変更が回避されます。ただし、そのためには、変更が「機能する」かどうかを簡単に確認できる必要があります。

これは、2番目のアイデアが出てくる場所であり、はるかに人気がありました。CIサーバーは、可能な限り迅速に変更がテストされるクリーンな環境です。ビルドを再現できるように、クリーンな環境が必要です。一度機能すれば、常に機能するはずです。これにより、「私のマシンでは機能していました」という問題が回避されます。特に、CIサーバーは、ソフトウェアが異なるシステムまたは異なる構成で実行され、すべてが機能することを確認する必要がある場合に役立ちます。

ビルドステップの欠如は無関係です。ただし、CIはテストスイートがある場合にのみ意味を持ちます。このテストスイートは自動である必要があり、失敗してはなりません。テストが失敗した場合、適切な開発者は、導入した問題を修正できるように通知を受け取る必要があります（コンパイルとしてビルドがない場合でも、「ビルドを壊す」）。

このようなサーバーは、単なるテスト以上の価値があることがわかりました。実際、ほとんどのCIソフトウェアは、さまざまな構成でテストを実行するのは本当に安っぽいですが、あらゆる種類のジョブを管理するのは得意です。たとえば、「継続的な」単体テストに加えて、夜間ビルドとして完全なテストが行​​われる場合があります。このソフトウェアは、複数のPythonバージョン、異なるライブラリバージョンでテストできます。Webサイトのリンク切れをテストできます。コードに対して静的分析、スタイルチェッカー、テストカバレッジツールなどを実行できます。ドキュメントを生成できます。すべてのテストスイートに合格すると、パッケージ化プロセスが開始され、ソフトウェアをリリースする準備が整います。これは、常にデプロイ可能な（およびデモ可能な）製品が必要なアジャイル設定で役立ちます。Webアプリの登場に伴い、継続的な展開のアイデアもあります：すべてのテストに合格すると、変更を本番に自動的にプッシュできます。もちろん、これには、テストスイートに本当に自信があることが必要です（そうでない場合は、より大きな問題が発生します）。

確かに、ビルドを実行してそれらのビルドが正しいことを確認するためにCIシステムを特に必要とするわけではありませんが、それはCIの一部にすぎません。

CIの目的は、エラーをできるだけ早く検出することです。一般的に言えば、エラーが早期に検出されるほど、修正のコストが安くなるためです。そのため、ビルド手順が不要な場合でも、CIシステムはコード分析ツールの使用、テスト環境への展開、ユニット/統合/回帰/自動化できるその他のテスト、およびその他の手順を自動化できます。エラーをチェックするために自動的に実行できます。

継続的インテグレーションは、コードのコンパイル以上のものを実行します。それがすべてであるならば、それのためにそれほど多くのツールを必要としないでしょう！

継続的インテグレーションパイプラインが頻繁に実行するオフハンドの考えられる他のタスク：

• 自動テストの実行。（Pythonには豊富な自動テストライブラリがあり、PHPには少なくともいくつかのライブラリがあります。MATLABと話すことはできません。）
• 配布用のソフトウェアをバンドルします。このプロセスを自動化することにより、毎回、正確で一貫性のある反復可能な方法で確実に実行されます。手順は忘れられません。このような配布パッケージを生成するには、多くても1クリックしかかかりません。（Pythonアプリをホイールとしてバンドルするのは素晴らしいアイデアです！）
• マイルストーンコミットのタグ付け。実稼働用のパッケージをビルドするときはいつでも、タグを付けたいと思うでしょう。
• 自動インクリメントバージョン番号。通常、これは単に「ビルド」番号であり、より意味のある部分ではありませんが、特定のビルドを一意に識別すると便利なため、どこにデプロイされているかがわかります。

厳密な意味で「継続的統合」の境界線に少し進んで、次のこともできます。

• オペレーティングシステムをセットアップし、依存関係をインストールするための自動化プロセスがあります。
• ソフトウェアのコピーを自動的に展開します（主にWebアプリケーションまたはパッケージマネージャーによって配布されるソフトウェアに役立ちます）。一部のチームは実際にこれを使用して実稼働環境に展開します（継続的な配信）が、そうでない場合でも、これを活用して、コードの追加の非実稼働コピーを展開できます。私が働いている一部のプロジェクトでは、開発者がコードをテストしてからQAで使用できるようにするためのコピー、QAがテストするためのコピー、デモ用のより安定したコピーを用意しています。

ポイントはこれだけです。コードを作成するだけでなく、ソフトウェア開発プロセスで定期的に実行する必要があるタスクがあります。これらのタスクを自動化し、サーバーで実行することにより、

• 一貫したプロセス（StanとSallyが異なる方法で物事を行うことはありません。）
• コードに記録されたプロセスの知識（スクリプトを読むことができる人は誰でも、Sallyがそれを行うまたは方法を知っている唯一の人ではなく、展開に関係する手順を学ぶことができます。）
• プロセスの単純な複製（Webサイトの複数のコピーを展開するのが簡単：新しい構成を提供するだけです！）
• より徹底的なテスト（ボブは彼のページのみをテストしましたが、彼の変更はサリーのページを壊しました。サリーはファイルをコミットするのを忘れました。 。これらすべてを何らかの形で見ました。）

そして、おそらく思い浮かばない他の利点もあります。

ソリューションをコンパイルする必要はないかもしれませんが、構成ファイル/フォルダーパスなどを変更することで、CIが引き続き役立ちます。チームにいる場合は、変更をprodステータスにプロモートして展開します

Pythonコードを5つの異なるQAサーバーにデプロイし、異なるQAデータベースをポイントする必要があるとします。その後、自動テスト実行（CIによってトリガー）され、ビルドをプロダクションにプロモートし、すべてのプロダクションサーバーに適切な構成変更を加えてデプロイします。