| menu |
|
||||
|---|---|---|---|---|---|
| title | Validated Patterns - Tested tier | ||||
| weight | 44 |
The {tested} tier provides you with additional collateral and reassurance that the pattern was known to be recently working on at least one recent version of {rh-ocp}. Inclusion in this tier requires some additional work for the pattern’s owner, which might be a partner or a sufficiently motivated subject matter expert (SME).
If your pattern qualifies or meets the criteria for {tested} tier, submit your nomination to validatedpatterns@googlegroups.com.
|
Note
|
Each {tested} pattern represents an ongoing maintenance, support, and testing effort. Finite team capacity means that it is not possible for the team to take on this responsibility for all {solution-name-upstream}. |
For this reason we have designed the tiers and our processes to facilitate this to occur outside of the team by any sufficiently motivated party, including other parts of Red Hat, partners, and even customers.
In limited cases, the {solution-name-upstream} team may consider taking on that work, however please get in contact at least 4 weeks prior to the end of a given quarter in order for the necessary work to be considered as part of the following quarter’s planning process
A {tested} patterns have deliverable and requirements in addition to those specified for the Sandbox tier.
The requirements are categorized as follows:
- Must
-
These are nonnegotiable, core requirements that must be implemented.
- Should
-
These are important but not critical; their implementation enhances the pattern.
- Can
-
These are optional or desirable features, but their absence does not hinder the implementation of a pattern.
A {tested} pattern must continue to meet the following criteria to remain in the {tested} tier:
-
A {tested} pattern must conform to the common technical implementation requirements.
-
A {tested} pattern must be meaningful without specialized hardware, including flavors of architectures not explicitly supported.
Qualification is a {solution-name-upstream} Technical Oversight Committee (TOC) decision with input from the pattern owner.
-
A {tested} pattern must have their implementation reviewed by the patterns team to ensure that it is sufficiently flexible to function across a variety of platforms, customer environments, and any relevant verticals.
-
A {tested} pattern must include a standardized architecture drawing, created with (or at least conforming to) the standard {solution-name-upstream} tooling.
-
A {tested} pattern must include a written guide for others to follow when demonstrating the pattern.
-
A {tested} pattern must include a test plan covering all features or attributes being highlighted by the demonstration guide. Negative flow tests (such as resiliency or data retention in the presence of network outages) are also limited to scenarios covered by the demonstration guide.
The test plan must define how to validate if the pattern has been successfully deployed and is functionally operational. Example: Validating an Industrial Edge Deployment.
-
A {tested} pattern must nominate at least one currently supported {rh-ocp} release to test against.
-
A {tested} pattern must ensure the test plan passes at least once per quarter.
-
A {tested} pattern must create a publicly available JSON file (for example, in an AWS bucket) that records the result of the latest test for each combination of pattern, platform, and {rh-ocp} version. See testing artefacts.
|
Note
|
A {tested} pattern does not imply an obligation of support for partner or community operators by Red Hat or the pattern owner. |
-
A {tested} pattern should be broadly applicable.
-
A {tested} pattern should focus on functionality not performance.
Teams creating {tested} pattern can provide their own service level agreement (SLA).
A technical document for Quality Engineering (QE) team that defines how to validate if the pattern has been successfully deployed and is functionally operational. For example, see Validating an Industrial Edge Deployment.
A {tested} pattern meeting additional criteria can be nominated for promotion to the Maintained tier.