だから私はvagrant + gitでワークフローを開発しています...これは理にかなっていますか？
関連する背景の詳細
- 開発者が必要とする2種類のVM（ユーティリティボックスとWebサーバー）があります。
- バージョン管理にはgitを使用します。
- 作業環境（たとえば、一部のLinux、一部のWindows）に異なる好みを持つ開発者がいます。
- 私はLinuxキャンプにいるので、GitとWindowsはLinuxとGitほどうまく混ざっていないと思います。しかし、これは個人的な偏見かもしれません。
- 本番環境ではLinuxを使用しています。
配布用のVagrant VMの構築
- Vagrantに関連するOSでベースボックスを構築します。
- 構成マネージャー（Chefなど）を使用して、Utility＆Webイメージを構築し、新しいベースボックスに変換します。一元化されたgitリポジトリからサービス構成を複製します。
- ユーザーがvagrantを使用してローカルで開発できるように、ベースボックス（実際には仮想マシンイメージのみ）を配布します。配布されたボックスは、特定のgitリポジトリ（ライブラリなど）からソースコードを自動的に取り込みます。
- 本番環境の変更が計画されている場合、すべての開発者は、パッケージ済みのvagrantの新しいベースボックスをプルダウンする必要があります。これは、新しい開発者が対処する最も簡単な方法だと思います。ステージングは、準備中の新しい開発VMに合わせて更新されます。
開発者ワークフロー
- 課題トラッカーから課題を割り当てます。
- Vagrant VM=を使用して、現在の開発リポジトリをホストOSと共有するフォルダーに複製します（開発者がお気に入りのIDEを使用できるようにするため）。
- 開発者はローカルで変更とテストをコミットします。
- 満足すると、Developerは自分の変更をdevリポジトリにマージします。競合する場合は、開発者と協力して競合するコードをコミットし、問題を解決してください。
- Devが安定した状態になると、Devは、新機能のQAのために現在のステージングリポジトリとマージされます。ステップ6が完了するまで、Devからステージングに何もプッシュされません。フックは、ステージング用のドキュメントの新しいコピーを生成します。
- QAが完了すると、ステージングが本番環境に複製されます。フックは、プロダクション用のドキュメントの新しいコピーを生成します。
上記に明らかに追加されている「ベストプラクティス」と見なされている明確な欠陥や落とし穴はありますか？
あなたの計画は素晴らしいですね！あなたは本当に良いスタートを切っていると思います。
私の唯一のアドバイスは、あなたの開発者ワークフローに関してです。私はあなたがdevブランチを問題とするかもしれないと思います、なぜなら開発者はコードを意のままにマージするからです彼らは準備ができていると思います。
BranchAとbranchB、C、およびDの両方がdevにマージされて失敗した場合、どの部分が必ずしも失敗しているのかはわかりません。また、誰かが衝突を起こして何かを押し上げた場合、それが誰であったかはわかりません。狂気と狂気は続いて起こるはずです。
機能の準備が整っていないことが判明し、コードをdevからバックアウトする必要がある場合、他の開発者はすでに追加をプルダウンしています。その後、これらの開発者はdevにマージし、壊れたコードを無意識のうちに再導入します。狂気と狂気は続いて起こるはずです。
テストされていないコードをテスト済みのコードから遠ざけるには、いくつかの分離ステップが必要になります。
これはすべて、チームのスキルセット、および実際の連携方法によって異なります。以下は、さまざまなレベルのgit知識とさまざまなレベルの開発者コードの信頼性を備えた、急速に拡大するチームの問題に対する私の解決策です。
私は常に、開発者のワークフローだけでなく、テスト手順、リリースプロセスについても考えるように人々に伝えようとしています。それらはすべて、単一のプロセスの一部として計画する必要があります。
- Lead DevまたはRelease Mngr（誰でも）が
releaseに基づいて新しいmasterブランチを作成します。このブランチは、次のリリースでのブランチのコンテナになります。 - Lead/ReleaseMngrは、リリースに基づいて
integrationブランチを作成します。 - 開発者は、現在のリリースブランチに基づいて、新しい機能ブランチ（またはトピックブランチ、必要に応じて何でも）を作成します。
- 開発者はローカルでテストし、満足しています。
- 開発者は、どこかに展開され、テストされていないコードのQA 独立してによってテストされたブランチを備えています。
- QAは機能を承認します-
integrationブランチにマージされます。 （理想的には、IMHO、機能ブランチがreleaseに基づいてリベースされた後でのみ、競合の解決を強制します） - QAは
integrationブランチとこれだけの機能であるreleaseブランチをテストします。 - QAサインオフ-統合はリリースにマージされます（サインオフしない場合、統合は中止され、
releaseに基づいて再作成されます）。これがintegrationの理由です。誰もこのブランチを引っ張ることはなく、必要に応じて吹き飛ばすことができます。 - 現在、この機能はリリースされており、
releaseブランチに基づいて機能を作成している他の開発者と共有できます。 - リリースは良好です。マスターにマージしてください。デプロイし、マスターに基づいて新しいリリースブランチを作成します。
私はそれがたくさんのように聞こえることを知っていますが、それは本当に頭痛からあなたを救うでしょう、そして、私の経験では、異なるレベルの知識を持つ人々のログを持つ大規模なプロジェクトでは避けられません。
単純なリリースプロセスを持つ小さなチーム、または非常に経験豊富なチームがある場合-これはすべて必要ではないかもしれませんが、dev ブランチ。
そうは言っても、GitHubチームが理解しているのは、簡単なコードレビューの後に、GitHubチームが直接マスターにマージし、1日に最大30回自動デプロイすることです。
一般的なアウトラインはいいですね。私が変更する唯一のことは、ベースボックス自体が自動更新されることです。おそらく、プロビジョニングスクリプトもgitにあるため、適切に構成された/etc/rc.localスクリプトによってボックスを自動的に更新できます。ベースボックスには、起動に必要な最低限のものがあり、構成に必要なすべての部分をダウンロードする必要があります。これにより、ボックスの配布を実際の更新プロセスから切り離すことができ、OSのアップグレードを除いて、変更を行うたびに新しいベースボックス全体を出荷する必要がなくなります。