ジュニアプログラマーと継続的に展開できますか？

マイクロサービスアーキテクチャでは、すべてのマイクロサービスを一度にデプロイして、すべてが連携して動作することを確認するために1週間待つのが、APIバージョン管理を厳密に強制し、多くの自動テスト（それぞれ：ユニットと探索、統合）、およびステージ上のテストとしてコミットが合格するとすぐに本番環境に自動展開します。

これで、テストを書き、コミットする前に変更をテストし、APIバージョン管理の使用方法を知っていて、展開時に実行されるインクリメンタルdb更新スクリプトでデータベースを削除しない限り、素晴らしいアイデアのように見えますステージで失敗するため、大きな問題ではありません）。

しかし、若いプログラマーでそれを行うことは可能ですか？たぶん、プルリクエストスキーマを実装する必要があります。これにより、継続的な展開のようになります（私の推測です）。

これが意見に基づいたものではなく、あなたの経験を共有してくれることを期待しています。ありがとうございます。

CIについても、継続的な配信についても質問していないことに注意してください。すでにあります。現在私たちが試みているのは、コードをチェックインした直後にすべてを本番環境に配置することを意味する、継続的な展開にすることです。

何故なの？継続的な展開を使用するかどうかに関係なく、説明することはすべて問題になります。問題は、後輩が壊滅的な間違いを犯すことを心配しているようです。そして、その間違いは誰でもキャッチできる前に本番に突入します。

そのため、コードのレビューとテストを行います。マスターブランチに何かをマージしてリリースの予定を立てる前に、他のジュニア（経験を積むため）と上級開発者（専門知識を使用してコードを改善するため）の両方でコードをレビューする必要があります。誰もがこれらの壊滅的なバグを探しているはずです。そして、それらを停止する必要があります。そうでない場合は、おそらくステージング環境でのより良いQA /テストが必要です（コードレビューがこれらのことを見逃している場合は、おそらくより良い開発者もいます）。

自動テストの優れたセットがあれば、継続的な展開はうまく機能します。

ジュニア開発者は、自分のタスクに興奮することができますが、彼らが物事を壊すことに気付かないのです。これを自動化することで修正できます。常にテストを実行するビルドサーバーをセットアップし、CatLight build notifierのようなツールを入手します。彼らが物事を壊したとき、それは彼らに迅速かつ明確なフィードバックを与えます。

発生した小さな問題を修正し、継続的な配信を継続します。

良い習慣を習得する唯一の方法は、それらを実践することです。そのため、ジュニア開発者も継続的な展開を実践できます。テストカバレッジをチェックし、場合によっては静的コード分析を実行し、テストカバレッジが十分に高くない場合にビルドを失敗させるなどのことを行うために、パイプラインにステップを追加することを考えてください。それにより、何かが完全であると見なされる前に、ジュニア開発者が期待を理解できるようになります。

ジュニア開発者と一緒にこれを行うことができるだけでなく、あなたに必要です。第一に、そうでない場合はソフトウェアの品質が低下し、第二に、これはジュニア開発者が優れたソフトウェア開発スキルを学ぶのに役立ちます。

類推として：あなたの医者は、若い見習いの間違いを恐れるので、彼の知識の及ぶ限りでは薬を練習しないでしょうか？医師は潜在的な損傷にどのように対処しますか？

多くの監督されていないジュニア開発者の手で長年自然に進化したBig Ball Of Mudコードベースの過去の経験から、これらの開発者とCIを練習しないとどうなるかを指摘したいと思います。

編集/更新：RubberDuckのコメントによる。この回答は、統合のマージターゲットが評価またはリリースブランチではなく開発ブランチであることを前提としています。

• 明らかに、リリースおよびライブ展開のためのコードをより多く制御する必要があります。独立した本番ブランチがない場合は、ブランチ/マージ戦略を変更して、マスターリリースブランチと共にマスター開発ブランチ（統合テストに使用され、リリースには使用されない）を実行することを検討する価値があります。これにより、実動コードを壊す危険を冒すことなく、CIと頻繁なマージのすべての利点が維持されます。

1.ジュニア開発者は、同僚や監督者と通信する可能性が低い

継続的インテグレーションは、単にコードをマージするだけの問題ではなく、開発者が他の利害関係者と対話することを余儀なくされる時点です。

コミュニケーションは重要であり、過度に一般化することを望まずに、チーム環境での作業に慣れている開発者よりも、経験の浅い開発者の方が自然に少ないスキルを習得する傾向があります。

ジュニア開発者が頻繁にレポートやレビューを求められることなく、キュービクルに座って数週間コードをバッシングすることを許可すると、コミュニケーションを完全に回避する可能性が高くなります。

2.作成中のコードは、より厳密なレビューが必要になる可能性が高い

以前に拾い上げて、書かれることを防止したかったほど悪いものをレビューしたことがありますか？これはよく起こります。

悪いコードが書かれることを防ぐことはできませんが、無駄な時間を制限することはできます。頻繁なレビューとマージを行うと、無駄な時間の範囲を最小限に抑えることができます。

最悪のシナリオは、自分たちのミニチュアプロジェクトで数週間、後輩の開発者を放っておくことです。そして、最終的にコードレビューの準備ができたとき、彼らが全体の混乱を投げるのに十分な時間が残っていません。離れて最初からやり直します。

多くのプロジェクトは、手遅れになるまで誰も注意を払っていないときに、大量の不良コードが書き込まれたというだけで、泥の大玉になります。

3.ジュニア開発者または他の新しいチームメンバーが要件を理解していることについて、あまり確信が持てないはずです。

開発者が間違った問題に対する完璧なソリューションを構築する場合があります。これは通常、プロセスの早い段階で誰かが正しい質問をした場合に簡単に回避できる単純な誤解に基づいているため、悲しいものです。

繰り返しますが、これは、要件の知恵を押し戻して質問する代わりに、額面で「悪い」要件を受け入れる可能性が高い、経験の浅い開発者に影響を与える可能性が高い問題です。

4.共通のパターン、既存のコードのアーキテクチャ、およびよく知られているツールとソリューションに慣れていない可能性が高い

開発者は、より良いソリューションが存在することさえ知らなかったという理由だけで、ホイールを不必要に再発明するのに全時間を費やすことがあります。または、彼らは何が間違っているのか分からずに丸い穴に四角い釘を打ち込もうとして数日を費やすかもしれません。

繰り返しますが、この種のことは経験の浅い開発者に起こる可能性が高く、問題に対処する最善の方法は定期的なレビューを確実にすることです。

5.コードのコミット/マージの間隔が長いと、欠陥の特定と修正が困難になります

数週間分のコード変更がmasterブランチにマージされた直後にバグが発生した場合、どの変更がバグの原因である可能性があるかを特定するのはより困難になります。

明らかに、全体的な分岐戦略もここで有効になります。理想的には、すべての開発者が自分のブランチまたは機能ブランチ（または両方）で作業し、マスター/トランクから直接作業することはありません。

チーム全体が同時にマスター/トランクに直接取り組んでいる状況を見てきましたが、これはCIにとってひどい環境ですが、幸運なことに、マスター/トランクから全員を引き離すというソリューションは、一般に個々の作業に十分な安定性を提供しますアイテム/チケット/など

開発者がmaster / trunkブランチを壊すことは常に「OK」である必要があります。マージは定期的に行われるべきであり、変更や欠陥をより迅速に特定し、したがってより迅速に解決する必要があることを理解してください。最悪の欠陥は通常、数か月または数年も検出されないままの欠陥です。

要約すれば; 継続的統合/継続的展開の主な利点は次のとおりです。

• チーム間のコミュニケーションが改善されます
• コード品質は通常、より高い標準で維持されます
• 要件が見落とされたり誤解されたりする可能性が低くなります
• アーキテクチャと設計の問題をより迅速に検出する必要があり、
• 欠陥はより早い段階で検出され修正される可能性が高い

したがって、ジュニア開発者とCIを実践していない場合、多くの不必要なリスクを受け入れることになります。これらは、他のチームよりもそれを必要とするチームのメンバーだからです。

はい、ジュニア開発者とCIを練習できます。現在の開発環境ではないのは愚かでしょう。レポジトリにプッシュし、それをステージングコードに自動的にマージして、すべてをTravis（またはBamboo、Pipelinesなど）でリアルタイムで見ることができると、非常に便利です！

あなたのDevOpsの人を連れて、彼らに彼らと一緒にプロセスを経験させてください。そして、物事を見守り、コードレビューとリンクさせるために、待機中の上級開発者に任せてください。

あなたの懸念がシテコードが通り抜けようとしているのであれば、それはCIにはなく、ジュニアにもありません：あなたにあります。

だから、彼らがより良くなり、ステージ/製品コードをより速く展開することに慣れるのを助けてください。長期的には自分自身に感謝します。