今日は、TrueEngineeringチームがProdに出荷するときに製品の品質を保証するために使用する基準を共有します。
「製品対応」とはどういう意味ですか？開発者ごとに、この質問に対する回答が異なる場合があります。そして、一般的にアイデアは一致するかもしれませんが、遅かれ早かれ、どのチームも同じ位置から製品を見て安定した結果を生み出すことができる特定の言語を開発する必要があります。
これらの統一されたビューは、ProductionReadの概念を構成します。製品が満たす必要のある要件にチームが同意すると、開発者が作業しやすくなります。誰もが準備の概念に単一の意味を置きます。つまり、結果は開発者ごとに変わりません。何らかの理由で必要ないと考えたために、誰かがロギングを開始しなかったということはありません。プロジェクトマネージャーは頭痛の種が少なく、製品がどのような状態で受け取られ、何が顧客に保証されるかを知っています。
私たちの一連のProductionReady基準は、開発の外部世界からの私たち自身の知識とベストプラクティスを組み合わせたものです。この点は個別に強調する必要があります。他の人の経験をカーボンコピーとして取得する必要はありません。チームが独自の作業スタイルを持っている場合があります。主なことは、それが効果的であり、単一の基準に準拠しているということです。
では、私たちの製品が本当に本番環境に対応していることをどうやって知るのでしょうか？
プロジェクトの要件を満たしています。この条項は、まず第一に、そのような要件が存在することを前提としており、それらは形式化され、文書化されています。これには、顧客の要求、ユーザーの要求、および環境の技術的要件が含まれます。すべてのチームメンバーはこれらの要件を知っており、開発中にそれらによって導かれます。
この製品はよく考えられたアーキテクチャを持っています。つまり、自発的に形成されることはありません。ソリューションが事前に設計されている場合、そのアーキテクチャは考えられるリスクと開発の見通しを考慮に入れます。このアプローチにより、チームは製品のフォールトトレランスを検討し、必要な機能を提供する技術的手段を事前に決定し、それらの互換性を確認できます。そうしないと、将来的には、製品の基本モジュールをやり直さずに目的の機能を実装することが不可能であることが明らかになる可能性があります。他の基準はアーキテクチャによって異なります-私たちは何度もそれに戻ります。
. 100- ( ). , . , – , . , , mock-. – .
. , 100% , SLA. , - . - . , SLA, .
. , , . , , .. . - – , , , .
. , . , , . , , , . , , .
. , . – , .. .
. , , , . , , Gitlab, , .
. , , . , : -, , , ..
Unified Production Ready Criteriaは、誰が製品を作成したか、誰が特定の各プロジェクトを管理したかに関係なく、同じ結果を達成するのに役立ちます。チームのためにシンプルで透過的かつ論理的な開発ルールを構築したいすべての人に、この方法を採用することをお勧めします。