Deployment configurations

Separating configuration from code is a key best practice for the development of scalable and resilient applications. In what follows, we explain the use cases for deployment configurations; how they are supported in CodeNOW; and provide examples of deployment configurations.

For more information, see:

• How to create a deployment configuration
• How to modify a deployment configuration
• How to modify a configuration template
• Custom stacks

Use cases

Deployment configurations lets you specify configuration parameters that can influence both the deployment and runtime behavior of your application. With those variables, you can deploy the same application in different ways in production and non-production environments. You can also pass configuration values to a running application (see examples).

Deployment configurations in CodeNOW

Create, reuse, modify deployment configurations. CodeNOW lets you store configuration values in configuration files and reuse those configuration files for several deployment targets. The set of provided configuration files for a specific deployment target is called a deployment configuration. Create, review, and edit CodeNOW deployment configurations at any time through CodeNOW's user interface. A lot of the time, you will create or edit deployment configurations while you are coding your application components. You can however also edit the deployment configuration at deployment time as part of the deployment process.

Specify a configuration template. Any configuration files that are in the /codenow/config folder of application components will be used as a default template the first time that you deploy to a target environment. Typically you would fill in the configuration files in the /codenow/config folder with variables that are common to all or many environments. When first deploying an application to a deployment environment, you can then edit the template and add environment-specific values and variables.

Many frameworks, libraries, or tools come with their configuration methods and parameters. For instance:

• ASP.NET uses configuration providers in tandem with appsettings.json and appsettings.[ENVIRONMENT].json files.
• The Create React App set of tools uses the browser window object and a runtime-configuration.js file to pass configuration variables to a running application.

For developers' convenience and productivity, every predefined scaffolder (e.g., Java/Maven/Spring Boot) includes default configuration files for their respective stacks in the codenow/config directory of application components' repository (cf. List of default configuration files). Edit the default configuration files as needed.

Make your own configuration files. You can additionally implement your own configuration mechanism. CodeNOW deploys, together with the application component’s code artifacts, any file contained in codenow/config directory of the component repository. Those files can be read by application components at runtime from the /codenow/config directory. Using your own configuration mechanism implies that you are responsible for the specifications, reading, and parsing of your configuration files. CodeNOW does not constrain in any way the meaning, usage, format, and number of deployment configuration files.

Examples

• The present documentation site is deployed in production with a noIndex parameter that toggles page indexing. Page indexing is important for SEO (search engine optimization) purposes. We want our documentation pages to be found by our customers so we enable page indexing in our production environment. However, the documentation site should not be indexed in dev. We achieve this difference in behavior with noIndex set to true (no indexing) or false (indexing enabled).

Example of deployment configuration

• The following configuration file may be used by a front-end application to parameterize its static messages and API endpoints. To reflect any change in the ticketsAPI endpoint, you would only need to redeploy the application:

helm-values.yaml

staticHeaderTextBig: "Welcome to TBD's status page hub!"
staticHeaderTextSmall: "You will find below the status information for each of TBD's services."
appName: stat-page-ui
domainName: www.tbd.com
ticketsApi: https://stat-page-service.tbd.com/tickets
linkHome: "/"
linkSupport: "/support"

Which deployment configuration is used when you do not specify one

You are likely to change your configuration variables less often than you change the code. This means you will often want to use the same deployment configuration for successive versions of the application. If you do not specify a deployment configuration, CodeNOW will reuse by default the deployment configuration that it thinks you most likely want to use for your deployment target.

That deployment configuration is selected from existing deployment configurations:

• the deployment configuration you provided in the application components’ repository
• deployment configurations used in previous deployments (see Create deployment configuration)

As the previous illustration shows:

• When deploying myApp v1.0 to the dev environment, CodeNOW will select the existing deployment configuration for that deployment.
• When deploying myApp v1.1 to the dev environment, given that there is no deployment configuration for the (dev, 1.1) target, CodeNOW will use the (dev, 1.0) one.
• When deploying myApp v0.2 to the prod environment, as before, CodeNOW will use the existing deployment configuration for the (prod, 0.1) target.
• When deploying myApp v0.2 to the test environment, given that there is no deployment configuration at all for the test environment, CodeNOW will create one from the configuration files in myApp’s components’ repositories.

Default deployment configuration templates for predefined scaffolders

As of February 2022:

Predefined scaffolder	Configuration files
C#/NuGet/.NET	appsettings.json
	appsettings.Development.json
Java/Gradle	startup-message.txt
Java/Maven/Micronaut	application.yaml
Java/Maven/Spring Boot	application.yaml
Java/Maven	startup-message.txt
JavaScript/npm/React	runtime-configuration.js
JavaScript/npm/Storybook for React	runtime-configuration.js
PHP/Composer	myconfig

Tips

• The parameters in configuration files generally change at a much lower frequency than the application’s code. Most of the time, you will deploy to a given target environment a new version of an application package with the same set of parameters as the previous version. CodeNOW recognizes this; and when you deploy a new application package version to the same target environment, CodeNOW will reuse the previously deployed version’s parameters. You will still be able to edit those parameters if need be. However, most of the time, you will not need to. CodeNOW thus helps you be more productive so you can spend most of your time on coding rather than on configuration.