ジュニアプログラマーの配置方法
私はジュニアプログラマーを雇っただけで、彼は私の隣に2番目のプログラマーになります。
私たちのソフトウェアは、gitflowワークフローを使用してgitで構造化されています。私は通常、開発ブランチで直接開発およびプッシュします。
コミットがプッシュされると、TeamCityとOctopusによって直接ピックアップされ、dev.domain.comドメインの下のテストサーバーにデプロイされます。
このようにして、QA担当者は私の変更をテストできます。
これで、ジュニアガイにはこの贅沢さはなくなり、開発ブランチに入るにはPRを作成する必要があります。それでも、QAが確認できるように、テスト環境に作業をプッシュできる必要があります。
これまでのところ、2つの解決策を考え出しました。
1：彼がコミットする単一のブランチを作成し、dev2.domain.comサイトに自動的にデプロイします。問題は、彼がこのブランチで新しいコードを開発し続けるため、PRを行うのが難しいことです。
2：すべての新しい機能について、TeamCity + Octopusの構成を自動的に作成するスクリプトを作成し、feature.domain.comサイトに展開し、機能がマージされたときに再び破棄します。利点は、機能が含まれているためPRが非常に簡単であるということです。欠点は、テスト環境をセットアップする必要があり、時間+サーバーリソースがかかることです。
他のチームはこのワークフローをどのように管理しますか？
編集：ポイントが行き渡っていないようです。私のコードは、他の人のコードとまったく同じ手順を実行します。しかし、問題はテスト環境をどのように構成するかということでした。機能ブランチを作成した場合、マネージャーとQAはそれらにどのようにアクセスしますか？ TeamCityとOctopusで手動で設定する必要がありますか？それが私が開発をプッシュする理由です、それは私たちのテスト環境にそのように展開されます。
私は通常、開発ブランチで直接開発およびプッシュします。
当然のことながら、これは問題です。 Nobodyは、gitflowを使用している場合はもちろん、開発に直接プッシュする必要があります-すべてが機能ブランチに移動し、機能が完了したら、開発にマージする必要があります。機能の開発の途中で優先順位が変更され、別の機能を最初に完了する必要がある場合はどうしますか？
また、プロジェクトに取り組んでいる別の開発者がいるので、コードもレビューしてもらう必要があります。直接開発する場合は、それを行うことはできません。
他のチームはこのワークフローをどのように管理しますか？
ラインのある時点で、テスト開発（または候補リリースを含む別のブランチ）を行う必要があります。そうしないと、機能間の相互作用を見つけることができません。
マージして開発する前に個々のブランチでいくつかのチェックを実行するリソースもある場合、それはすばらしいことですが、通常、これらは完全な回帰タイプのテストではなく、その機能の変更をすばやくチェックする必要があります。
@フィリップの優れた答えに追加するには、これを人間の視点からも検討する必要があると思います。
業務慣行を階層化すると、ジュニア開発者のスキルが損なわれます。高品質のゲートウェイがあることは確かに良いことです。チームワークと自己組織化を促進したい場合は、すべての人に等しく適用する必要があります。
私の考えでは、これは、良い習慣をセットアップするというよりは、コードを握っているということです。自問してみてください。もしあなたが自分よりも経験の豊富な開発者を雇っていたら、すべてのコードをレビューして承認してもらえませんか？
@Philipがすでに指摘したように、理想的には、そもそも開発ブランチで直接作業していないことが理想的です。
この回答 少人数または1人のチームでさえ、機能ブランチを使用することが良いアイデアである理由を私にうまく要約します。
あなたと新しい開発者のために（そして将来の各新しい開発者のためにも）個人用の開発スペースをセットアップすることをお勧めします。これにより、別のブランチで機能に取り組み、完了したらプルリクエストをセットアップできます。 （これは自動化されたテストのためのイングレスの良いポイントであり、また、ジュニア開発者にあなたの仕事を示す/彼の仕事を見る機会でもある）そしてテストがパスしたら、PRを処理し、機能を開発ブランチに置くQAチームがチェックして、自分の仕事を行うことができます。
これらの個人的な開発スペースは、docker/vagrant、別のサーバーなどを使用してローカルに配置できます。これは好みの問題です。
このアプローチの利点は、ワークフローの将来性を保証することです。プロジェクトに取り組んでいる開発者の数がワークフローを変更しないシステムを導入しています。彼ら全員が独自の開発環境を手に入れ、機能に取り組み、PRを作成します。最終的には開発ブランチに到達し、QAによって処理されます。
このようにして、QAチームはまだ1つのポイントを確認するだけで、複雑さが軽減されます（機能/開発者ごとに個別のURLを追跡する必要がないため）。