CIはインタープリター型言語にどのように使用できますか？
これまで継続的インテグレーションシステム（CI）を使用したことがありません。私が主にMATLABでコーディングしているPythonまたはPHP。これらのどちらにもビルドステップがなく、CIがどのように私の作業に使用できるのかわかりません。大規模プロジェクトの友人会社は私に言語は問題ではないと言った。
ビルドステップがない場合、CIがどのように役立つかわかりません。 CIは単体テストを実行するテスト環境と考えることができます。何か不足していますか？
用語としての継続的統合は、2つの異なるアイデアを指します。
1つはワークフローです。つまり、チームの全員が自分のブランチで作業するのではなく、2週間のプログラミング後に変更をメインラインにマージしようとすると、その変更は（ほぼ）継続的に統合されます。これにより、問題が早期に表面化し、互換性のない変更が回避されます。ただし、そのためには、変更が「機能する」かどうかを簡単に確認できる必要があります。
これが2番目のアイデアの出番です。 CIサーバーは、変更が可能な限り迅速にテストされるクリーンな環境です。ビルドを再現できるように、クリーンな環境が必要です。一度動作すれば、常に動作するはずです。これは、「しかし、私のマシンでは機能しました」という問題を回避します。特に、CIサーバーは、ソフトウェアが異なるシステムまたは異なる構成で実行され、すべてが正常に機能することを確認する必要がある場合に役立ちます。
ビルドステップの欠如は無関係です。ただし、CIは、テストスイートがある場合にのみ意味があります。このテストスイートは自動である必要があり、失敗してはなりません。テストが失敗した場合は、適切な開発者が通知を受け取り、導入した問題を修正できるようにします（コンパイルとしてビルドがない場合でも、「ビルドを壊す」）。
このようなサーバーは、単なるテスト以上の価値があることがわかります。実際、ほとんどのCIソフトウェアは、さまざまな構成でテストを実行するのは本当に簡単ですが、あらゆる種類のジョブの管理には適しています。例えば。 「継続的」な単体テストに加えて、ナイトリービルドとして完全なテストを行うことができます。ソフトウェアは、複数のPythonバージョン、異なるライブラリバージョンでテストできます。Webサイトでデッドリンクをテストできます。静的分析、スタイルチェッカー、テストカバレッジツールなどを実行できます。コード。ドキュメントを生成できます。すべてのテストスイートに合格すると、パッケージ化プロセスが開始され、ソフトウェアをリリースする準備が整います。これは、常に展開可能な（およびデモ可能な）製品が必要なアジャイル設定で役立ちます。 。Webアプリの台頭に伴い、継続的デプロイメントのアイデアもあります。すべてのテストに合格すると、変更を本番環境に自動的にプッシュできます。もちろん、これにはテストに本当に自信があることが必要ですスイート（そうでない場合、より大きな問題があります）。
確かに、ビルドを実行してそれらのビルドが正しいことを確認するCIシステムは特に必要ありませんが、それはCIの一部にすぎません。
CIの目的は、エラーをできるだけ早く検出することです。これは、一般的には、エラーを早期に検出する方が、修正するのが安くなるためです。そのため、ビルドステップが不要な場合でも、CIシステムは、コード分析ツールの使用、テスト環境へのデプロイメント、自動化できるユニット/統合/回帰/その他のテスト、およびその他のステップを自動化できます。エラーをチェックするために自動的に実行できます。
継続的インテグレーションは、コードのコンパイル以上のものを実行します。それだけの場合は、それほど多くのツールは必要ありません。
継続的インテグレーションパイプラインが頻繁に実行する、手に負えない他のいくつかのタスク：
- 自動テストの実行。 （Pythonには自動テストライブラリが豊富にあり、PHPには少なくともいくつかあります。MATLABと話すことができません。）
- ソフトウェアを配布用にバンドルする。このプロセスを自動化することで、毎回正確で一貫性のある再現可能な方法で確実に実行できます。手順が忘れられることはありません。このような配布パッケージの生成には、せいぜいワンクリックで完了します。 （Pythonアプリをホイールとしてバンドルすることは素晴らしいアイデアです！）
- マイルストーンコミットのタグ付け。本番用のパッケージをビルドするときは、タグを付けたいと思うでしょう。
- 自動インクリメントするバージョン番号。通常、これは単なる「ビルド」番号であり、意味のある部分ではありませんが、特定のビルドを一意に識別して、何がどこにデプロイされているかを把握できると便利です。
厳密な意味での「継続的統合」の境界線に少し進むと、次のことも実行できます。
- オペレーティングシステムをセットアップし、依存関係をインストールするための自動化されたプロセスがあります。
- ソフトウェアのコピーを自動的に展開します（主に、パッケージマネージャーによって配布されるWebアプリケーションまたはソフトウェアに役立ちます）。一部のチームは実際にこれを使用して実稼働環境（継続的デリバリー）にデプロイしますが、使用しない場合でも、これを活用して、追加の非実稼働のコードのコピーをデプロイできます。私が取り組んでいるいくつかのプロジェクトでは、開発者がコードをQAで使用できるようにする前にテストするためのコピー、QAがテストするためのコピー、およびデモ目的のより「安定した」コピーがあります。
要点はこれだけです。コードを書くだけでなく、ソフトウェア開発のプロセスで定期的に実行する必要があるタスクがあります。これらのタスクを自動化してサーバーで実行させることにより、
- 一貫したプロセス（スタンとサリーが異なる方法で物事を行う必要はありません。）
- コードに記録されたプロセスの知識（スクリプトを読むことができる人は誰でも、Sallyがそれを行うか、またはその方法を知っている唯一の人であるのではなく、展開に関連する手順を学ぶことができます。）
- プロセスの複製の簡素化（Webサイトの複数のコピーを展開するのは簡単：新しい構成を提供するだけです！）
- より徹底的なテスト（ボブは自分のページのみをテストしましたが、彼の変更はサリーのページを壊しました。サリーはファイルをコミットするのを忘れました。スタンはアプリと一緒にインストールする必要がある新しい依存関係を追加しましたが、IDEによって自動的にインストールされるため、それを認識しませんでしたこれらすべてを何らかの形で見たことがあります。）
そして、おそらく思い浮かばない他のいくつかの利点もあります。
ソリューションをコンパイルする必要はないかもしれませんが、CIは構成ファイル/フォルダーパスなどを変更することで、またチームに属している場合、prodステータスへの変更をプロモートし、それらをデプロイすることで、引き続き役立ちます。
Pythonコードを5つの異なるQAサーバーにデプロイし、異なるQAデータベースを指す必要があるとします。その後、自動テスト実行（CIによってトリガーされます）が完了したら、ビルドを本番環境にプロモートしてデプロイします。そこには、すべての本番サーバーの適切な構成変更があります。