継続的インテグレーション/デプロイメント：コミット、プルリクエスト、または何をテストしますか？
CI/CDについて読んで気に入ったのですが、読んだ内容がすべて高レベルだったため、詳細に問題がありました。
一部の作成者は、リポジトリ（またはマスターブランチ？）で失敗したコミットはあり得ないと示唆しているようでした。テストに合格するように、コードを修正する必要があります。
他の人たちは、トリガーはコミットではなくプルリクエストであると述べました。私は正直に言うとプルリクエストをあまり使用していません。また、それらはgitの外部のものではありませんか？これらはgit AFAIKの一部ではありませんが、github、bitbucketなどのサービスの一部なので、ワークフローをそのようなものにバインドする必要があるかどうか確信がありませんでした。
これについての考えは私を大いに助けます。使用しているツールについても説明してください（例：Jenkins、Buildbotなど）。私が試したツールはどれも、とてもフレンドリーなIMOでした。ドキュメントと例には、Javaのような特定のテクノロジー、またはgithubのようなサービスが欠けているか、それらに関連付けられていませんでした。自分で構築することも考えました。基本的な機能を取得するのはそれほど難しくありません。正しい？
簡単に言えば、自分のチームに合った方法を実行してください。
完全な継続的デプロイメントのシナリオでは、これをワークフローとして使用できます。
- 特定のブランチへのコミット（集中型システム）またはプッシュ/プル（分散型システム）のたびに、コードのビルドがトリガーされます。
- ビルドが成功すると、ユニットテストがトリガーされます。
- それが成功すると、統合テストがトリガーされます。
- 統合テストに合格すると、ステージングシステムへのデプロイがトリガーされます
- デプロイが機能する場合、自動受け入れテストがトリガーされます
- 受け入れテストに合格すると、本番環境へのデプロイがトリガーされます
- それが機能する場合、いくつかの自動煙テストをトリガーする必要があります。
現在、現実の世界では、そのように機能することはめったにありません。各チームには独自のワークフローがあります。 QAとステージングのフェーズがいくつかある場合や、ビルドマシンから本番環境に直接デプロイする場合があります。手動のテストフェーズが必要な場合や、パフォーマンステストなどが必要な場合があります。
あなたとあなたのチームにとって最も意味のあるものを除いて、完璧な答えはありません。必要に応じてすべてのコミットでトリガーするか、特定のブランチへのプッシュでのみトリガーします。どちらが最適かは、あなたにとって何が重要で、どのようなテスト範囲を持っているかによって異なります。また、テストの実行にかかる時間にも依存します。コード行をコミットする前に30分待つ必要はありません。
そうは言っても、原則として、テストされるまで、コードを他の人に影響を与える場所に移動しないでください。
Ruby、Rails、rspec、およびjenkinsを次のワークフローで使用します。
- 開発者はブランチで開発し、単体テストを記述し、完全なテストスイートを実行します。
- 開発者がブランチをプッシュする
- qaはブランチをプルし、ブランチをマスターにマージし、マージの競合を解決してテストを実行します
- テストに合格すると、qaは更新されたマスターをプッシュします
- マスターのgit Pushは、完全なスイートを実行するためにci（jenkins）をトリガーします。