Overview

As you develop your application, you need to regularly deploy it. Deploying the application allows you to test it, and/or the targeted end users to use the new developed features. To deploy an application to the cloud with CodeNOW, you need to specify the following:

• what to deploy (e.g., application package)
• where to deploy to (e.g., deployment environment)
• how to deploy (e.g., configuration files, configuration of connected services, runtime configuration, assigned domains)

What to deploy. You may have several versions of your application in as many application packages. While you generally want to deploy the latest version of your application, this is not always the case. You may want to deploy a previous version of your application in case of deployment failure or a critical error showing up.

Where to deploy to. Some teams have one dev deployment environment for each team member. They may additionally have a CI, test, staging, and multiple prod environments (e.g., one per customer). With deployment environments, teams can fulfill different purposes (e.g., integration testing, user acceptance testing) separately without interference between environments.

How to deploy. You often need to parameterize the deployed application to fit the purpose of the target deployment environment. You may for instance want to turn down some features in non-production environments. You may also want to change an application's configuration at runtime (e.g., API URLs, theme data, connection strings). You would then change the relevant variables and possibly redeploy the application without ever touching the codebase or rebuilding the application. Not rebuilding the application saves computing resources. Not modifying the code ensures that you do not inadvertently introduce bugs. In other words, deployment configurations save you engineering time and money. Separating configuration and code is a fundamental practice for cloud-native applications.

CodeNOW already knows how to deploy application components that were created with its predefined scaffolders. You can however use any stack that does not match the existing scaffolders, how to do so is explained in Custom stacks.

Topics

• Deploy an application
• Configuration management
• Connect service to component
• Runtime configuration and scaling
• Domain name configuraiton
• API execution and testing

Tips

• Place deployment configuration data that is common to all deployment environments in configuration files in components' Git repositories (do NOT do this for secrets though). When you deploy an application, you will not need to edit again those common configuration values. You can extend the reasoning to configuration variables whose value changes infrequently. You will only have to edit their values sometimes.