「自動ビルド」とはどういう意味ですか？
プロジェクトに継続的インテグレーションを追加しようとしています。
Wikipediaへ によると、CIの主要な部分の1つは自動ビルドです。しかし、CIと ビルドオートメーション の記事が一致していないように見えるので、正確には、それが何を意味するのか混乱しています。
混乱の特定のポイント：「自動化されたビルド」の意味の文脈で：
- Python or Perl？
- エンドユーザーのマシンのソースからビルドしますか？
- ユーザーのマシンにローカルなRDBMS内のデータベースなど、単純にプリコンパイルおよび配布できない依存関係を持つアプリケーション？
一部のテクノロジでは、コンパイル手順が不要であることに注意してください。ただし、「ビルドの自動化」という用語を解釈するときは、より広い視野をとることをお勧めします。 「ビルド」は、次の2つの主要コンポーネントを含むと考えてください。
- エンドユーザーにデプロイされた変換ソースアーティファクト（コード、データベーススキーマ、ドキュメントなど）のプロセス。
- 上記の変革中の品質保証措置の適用
自動化とは、これらの操作のすべてではないにしても、自動化する（つまり、手動による介入を必要としない）ことを指します。これには、テクノロジーに応じて、さまざまな手順が含まれる場合があります。
変換手順：
- コンパイル
- リンク
- パッケージング
- 配備
- データ移行
- バックアップ
- 通知
品質保証の手順：
- コンパイラの警告/エラー
- 単体テスト
- 統合テスト
- システムテスト
- 展開認証
最近では、優れたCIツールを使用して、これらすべての懸念に対処できます。最初は、ほとんどのショップがコードのコンパイルの自動化に関心を持っています。これは、これが従来のソフトウェア開発における問題の最初の、そして最も目に見えるソースであるためです。
自動ビルドは、以下の基本をカバーする必要があるプロセスの説明です。
- ソース管理から最新のコードを取得する
- 最新のコードを実行可能ファイルにコンパイルします
- コンパイルされたコードに対してテスト（単体テスト、システムテスト、統合テスト）を実行する
- 完了した実行可能ファイルを既知の場所に展開します。
- ビルドの結果を公開します。
5.1コンパイルの成功、単体テストの成功
これは、手動の介入なしで実行する必要がある、ハンドオフのプロセスです。
私の考えでは、自動ビルドは
- スケジュールに従って、またはソース管理へのコミットごとに自動的に行われる
- 任意のサーバーに簡単にデプロイできる一連のアーティファクトを作成します
目的は、繰り返し実行できる展開プロセス（読み取り：テスト済み）を実現することです。これにより、運用環境に展開するまでに、問題が起こらないことが確実になります。ビルドプロセスとデプロイプロセスにおける人間の操作が少ないほど、リリースはより安全になります。
コンパイルされていない言語がある場合でも、サイトを構築し、それを圧縮して1つのアーティファクトを作成できます。
優れたCIツールを使用すると、単体テストの実行など、多くのタスクをビルドプロセスにスクリプト化できます。また、成功したビルドと失敗したビルド、テストカバレッジなどの記録も保持されます。ただし、これらのいずれも、自動ビルドとして定義するものの一部ではありません。 （つまり、優れた自動ビルドプロセスにはこれらの機能がありますが、適切でないものには「自動ビルド」と呼ばれることはありません。
統合/回帰テストは、ビルドプロセスではなく、デプロイメントプロセスの一部として実行することをお勧めします（ただし、便利な環境があれば、すべてのビルドでデプロイできます）。
a project using an interpreted language, such as Python or Perl?
インタープリター型言語の場合、物事はヒットまたはミスする可能性があります。一部の相互貫入言語にはコンパイラーがありますが、それらを使用する必要性はそれほど多くありません。その場合は、通常、コードの代わりに構文を解析して構文エラーを解析するか、コンパイルの代わりにコードをテストするだけです。
エンドユーザーのマシンのソースからビルドしますか？
私にとってこれは、エンドユーザーが実行できる単一のコマンドを提供して、プログラムの最新バージョンを取得し、それをコンパイルし、必要に応じて構成および展開できることを意味します。
ユーザーのマシンにローカルなRDBMS内のデータベースなど、単純にプリコンパイルおよび配布できない依存関係を持つアプリケーション？
データベースが自動的に破棄および再構築され、スクリプトが正しく、プログラムがそれを正しくテストできることを確認できるため、これらは継続的インテグレーションのテスト部分に該当します。
あなたがあなたの質問で議論しているのは、実際には3つの異なる概念です：
継続的インテグレーションは、そのコアで小さな変更を行い、それらの変更を「グローバルな真実」と頻繁に同期しています。チェックアウトをして1週間保持する代わりに、開発者は1日以内に完了することができるタスクに取り組み、コードがメインリポジトリと同期しすぎないようにする必要があります。
チームに苦痛を与えずにこれを達成するため（つまり、既存の機能を構築または破壊しないソースをチェックインする）。開発者は、自分のコードが「ビルドを破壊」しないことを確認する必要があります。手動で行うと、開発プロセスに追加のオーバーヘッドが追加されます（ビルドに長い時間がかかるプロジェクトや、1行のコードを変更するとアプリケーションに予期しない影響を与える可能性がある相互依存関係が多いプロジェクトを考えてください）。
この状況を軽減するために、他の手法を使用してこのオーバーヘッドを削除します。
自動ビルドを使用してソースをチェックアウトし、オプションで実行してビルドします自動テストアプリケーションが正常に動作することを確認します（この手順は、テストスイートと同じくらい有用です）。
次のステップ継続的デリバリーは、データベースやその他の問題に関する問題に対処します。ここでの考え方は、データベースと環境の他の要素にある程度のバージョン管理を提供して、アプリケーションができるだけ本番環境に近い環境で動作することを可能な限り迅速に確認できるようにすることです。
「自動ビルド」とは、1つの（スケジュール可能な）アクション（通常はシェルスクリプトまたはバッチファイル）でソース管理から出荷可能なパッケージに移行できることを意味します。
このコンテキストでビルドを正確に構成するものは、出荷するもの、ビルド方法、および開発スタックのさまざまな部分に必要な手順に大きく依存しますが、いずれの場合も、ソース管理に何があるか、そして出荷可能な製品（またはエラーメッセージと怒っているプロジェクトマネージャー）になります。
単純なPythonプロジェクトの場合、自動ビルドは、ソースのチェックアウトと関連ファイルの正しいディレクトリへのコピーという2つのステップのみで構成される場合があります。より複雑なプロジェクトの場合、次のようなことが含まれます。
- コンパイル、リンク
- 自動テストの実行
- インストーラーパッケージの作成
- インストール
- データベースの変更
- バックアップの作成（ロールバックする必要がある場合）