Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,363,168
Community Members
 
Community Events
168
Community Groups

Deployment environment challenges

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?

1 answer

1 accepted

0 votes
Answer accepted
Max Malygin Community Leader Jan 10, 2020

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.

Suggest an answer

Log in or Sign up to answer
TAGS

Atlassian Community Events