This section outlines best practices for deploying to new Environments. These recommendations are helpful in several scenarios, such as:
Modules are an Apollo resource that allow you to define groupings of Products and configuration overrides. You can then deploy Modules to multiple Environments, export them to new Hubs, or manage existing Products in your Environments. This is helpful when your platform consists of several Helm charts that each need to be installed or you manage a fleet of Environments and want to ensure installations and configurations are aligned across the fleet. Additionally, you can set Product dependencies across Releases to ensure Products are installed in the correct order on your new Environment.
We recommend creating a Git repository for Modules where you store the definition of your Module. This allows you to version-control your Module definition and automatically publish the new definition to Apollo in your CI pipeline.
When you deploy a Module to an empty Environment, the Module will trigger installation Plans for the Products in the definition. If you deploy a Module to an existing Environment, the Entities in that Environment will automatically be managed by the Module. Both of these actions create a change request where you can view what changes the Module is proposing to the Environment, whether it is a product installation, configuration change, or no action against an existing Entity.
When you make changes to the Module, the updates propagate to each Environment that is already subscribed to that Module. This is useful if you have a configuration change across the fleet or if you want to install a new Product across the fleet as part of your platform. These updates will produce a change request that you can review to confirm the changes the Module wants to make in the Environment.
The following values should not be hardcoded in your application configuration, instead opting for Module variables or creating secrets during installation:
While some of these values may remain the same between Environments, we recommend abstracting the values to variables to ensure you have flexibility to perform operations like changing namespaces names or secret values. To manage secrets with the Module, see secret requirements in the Modules documentation.
When deploying to a new Environment, you should ensure the following resources are configured before deploying Entities to the Environment:
In addition to preparing a Module to deploy on your new Environment, you should develop a plan for these one-time changes you must make before deploying.
You can leverage Product evaluation and promotion to determine which products are delivered to various Environments. In the Module definition, you can specify a Release Channel variable to instruct which Releases are installed to that Environment. This allows you to ensure Modules deployed to specific Environments follow the correct Release Channels for those Environments, like ensuring production environments follow all the requirements for a production product installation.
Some examples of evaluation criteria include
security-scan-outcome label.