This article is designed to help guide you through implementing Replicated features into your application and more broadly into your organization. This includes recommendations for integration into your continuous integration environments, deployment manifests, and Vendor Portal and even further into things like how best to integrate your support process with ours and how to use the cloud native functionality that using Replicated brings to help you sell your own software.
As you go through this architecture we will include design decisions that were used to help you understand why a particular decision was made. You can use this knowledge to also help you understand when your particular situation means a different decision is advantageous. This architecture is meant to give you a path to success and not constrain your available options.
The way you build, release, and deploy your software is important to the success of running your commercial application in a customer-provided cloud-native environment. In this section, we explore the various components and decisions to best support deploying into those customer provided environments. We will cover the components of this architecture in more detail in the sections below.
Your software architecture is an important consideration as part of making your application ready to run in customer provided environments. In general, following the design considerations outlined in the 12 Factor App will help you build applications that are resilient to failure and scale well in any cloud-native environment, on-prem or otherwise.
Consider the following design decisions when building your application:
The most frequent intersection between Replicated and your own organization will be through the build process. We recommend that for every commit that passes your code quality checks, that you update container images you and promote the release to your unstable release channel. We also recommend signing your commits and container images to help validate the security of your supply chain.
Packaging your application is a core part of its delivery to customers. We recommend that you simplify your packaging by following some standards such as aligning the branch name of your package repository to the branch names of your release channel. Additionally, we recommend that you package your application as a helm chart so that you can allow customers the flexibility of installing via helm directly or via the application console.
When packaging your software we recommend you follow the design considerations below:
When a revision of your software has been tested and is ready to be released, we recommend that you use the package repository to communicate the changes they can expect in a release.
When releasing your software we recommend you follow the design considerations below:
Customer Delivery is the final customer initiated action that will result in your application being installed into their environment. For first time deployments, We recommend that you provide a clear and concise installation guide that will help your customers get started with your application. We also recommend that you provide a clear and concise upgrade guide that will help your customers upgrade to new versions of your application. You can use our documentation templates mentioned in the documentation architecture section to help you get started.
For customer deployments we recommend you follow the design considerations below:
By integrating the replicated platform into your support processes you can gain significant improvements by reducing total cases and time to resolution. To best leverage these features be sure to integrate the support bundles and support bundle analyzers into your support or incident process.
Documentation is an important part of all software. By using replicated, you can integrate our documentation into your existing documentation framework.
By using Replicated, you gain access to a host of features for your application that help you sell more and run proof-of-concepts (POCs) better.
This model has a worksheet with each of the decisions in a tabular format. You can copy this worksheet and for each decision here track if you are following the model or provide architectural notes on why a different decision was reached.