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
andappsettings.[ENVIRONMENT].json
files. - The Create React App set of tools uses the browser
window
object and aruntime-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 indev
. We achieve this difference in behavior withnoIndex
set totrue
(no indexing) orfalse
(indexing enabled).

- 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:
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 thedev
environment, CodeNOW will select the existing deployment configuration for that deployment. - When deploying
myApp
v1.1 to thedev
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 theprod
environment, as before, CodeNOW will use the existing deployment configuration for the(prod, 0.1)
target. - When deploying
myApp
v0.2 to thetest
environment, given that there is no deployment configuration at all for thetest
environment, CodeNOW will create one from the configuration files inmyApp
’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.