web-dev-qa-db-ja.com

githubを使用したコラボレーションとコードのテスト

私のチームの手順は、すべてのコードを同じ開発ブランチにコミットすることです。このブランチから更新されたコードを実行するテストサーバーがあり、サーバー上でコードをテストできます。このテストサーバーはインターネット上に公開されているため、sendgridなどのサードパーティサービスからのコールバックをテストできます。 (sendgridが送信メールのステータスを更新するためのURLを指定する場合)

問題は、新しい機能を運用サーバーに公開するために開発ブランチをマスターブランチにマージする場合、準備が整っていない可能性がある一部の機能が運用サーバーに適用されることです。

したがって、各開発者が機能/トピックブランチで作業し、それぞれが独自の機能で作業し、準備ができたら、開発用ブランチにマージしてテストし、次にマスターブランチにマージすることを検討しています。

ただし、テストサーバーは開発ブランチから変更をプルするだけなので、開発者は機能をテストできません。ローカルマシンでテストできるため、これは大きな問題ではありませんが、機能の開発中に、テストサーバーを使用してサードパーティサービスからのコールバックをテストする場合にのみ問題が発生します

この問題をどのように処理できますか?

注:gitの上級ユーザーではありません。 MacOSXおよびWindows用のGithubアプリを使用して、作業をコミットします。

セットアップ:これはPHP=プロジェクトです。CIセットアップの形式はなく、そのための知識もありません。最終的にはJenkinsを使用したいのですが、今は焦点を合わせています。私たちの最小限の実行可能な製品を出すことについて。

5
wyred

1つの解決策は、コミットが行われたときにテストサーバーにもブランチを構築させることです。たとえば、Jenkinsは、リポジトリ内の一部またはすべてのブランチを監視するように指示でき、ブランチへのコミットを検出すると、そのブランチを構築します。たとえば、 Git、Feature Branches、およびJenkins –または壊れたビルドについて心配するのをやめる方法を学んだ方法

テストすることを想定していない「スクラッチ」ブランチの命名規則を設定し、Jenkinsに「実際の」機能ブランチのみを構築させることができます。

もう1つの一般的な解決策は、機能ブランチとマスターの間にある種の統合ブランチを作成することです(またはブランチ「マスター」と「リリース」を作成する)。次に、機能の準備ができると全員がマスターにマージされ、すべてがマスターでテストされますが、「リリース」へのマージは、機能が十分にテストされてデプロイされた後にのみ行われます。たとえば、 成功したGit分岐モデル 1つの一般的なアプローチ。

3
sleske

Gitプロジェクトが「pu」ブランチで行うようなことを行うことができます。

Git(プロジェクト)では、トピックブランチで開発が行われます。開発中、これらのブランチは多くの場合、最新のmasterに基づいており、他の最近の開発に依存している場合はnextに基づいています。そして、それらがリベースされるたびに、それらはすべて、pと呼ばれるブランチにマージされます。ブランチは常に削除され、すべてのトピックを再度マージすることによって作成されます。機能がテストされるときよりも、それは「次へ」にマージされます。これは決してリバウンドされず、最終的に「マスター」に統合されます。したがって、この「pu」(開発)を示す1つのテストサーバーと、「次の」(試作)を示す別のテストサーバーを用意できます。

2
Jan Hudec