Deployment environment challenges

[jason apple]

My background is from using Octopus, where I could set up a list of environments and variables specific to them, then re-use them in all my deployment plans.

I plan to deploy 100 microservices, over a series of 40-50 environments.  Today, i feel like i have to recreate / clone all 50 environments for each new service.  And, if i have a change to one of the parameters,i have to touch hundreds and hundreds of deployment plans.

Most of what i store for an environment, is a set of credentials or information needed to deploy a service to a box or environment.  For example, if we choose QA-01, we know the boxes the deploy will go to, and have credentials for each.  Today, this seems entirely manual.

I've looked a "specs" but i'm not seeing how this makes it any easier.  Is this just how it is, or am i missing a concept such that environments can exist at a higher level then inside a deployment, or is there something else that helps me with deploys?

[Max Malygin · Accepted solution]

When using specs, you can automate making changes to the parameters of the environment after it is created / modified. You will need to download the specs file from the git repository, make changes to it (replace the values of the required environment variables) and execute git commit.

You can export the current settings to Java specs and learn what parameters need to be changed.

Unfortunately, Sensitive data encryption cannot be used in automatic mode, because all the data will be stored in the repository in the clear.