What’s the best workflow for multi-env?

Which Category is your question related to? multi-env

Amplify CLI Version 4.19

What AWS Services are you utilizing? API, Auth, Lambda, DynamoDB, S3

I realize that this is partially an Amplify Console question, but there is overlap, so I’m asking this here first, because my confusion mainly revolves around multi-env on my local.

I’ve read Team workflows with Amplify CLI backend environments, and it’s what I’m trying to follow as a guide.

And I’m admittedly confused, as I write this, so kindly keep that in mind.

If I’m working in an existing prod env that has been created with multiple back-end resources (e.g. auth, lambda, storage, etc.), and I do a amplify env add, adding a new develop env, followed by a amplify push, it modifies several files in the existing git branch (currently master) on my local that are specific to the new develop environment.

These include:

• team-provider-info.json
• cloud formation templates for lambdas
• aws-exports.js

team-provider-info.json seems fine to commit and push to master, and aws-exports.js is excluded so that’s okay too. But, from what I can tell, the cloud formation templates are updated with new values for the S3 deployment bucket.

If I’m in the master branch (git) when I do this, and I push those changes to an Amplify Console connected repo, won’t this result in the current front-end in the Amplify console talking to the back-end resources for the newly created amplify env?

If I’m in a develop branch when I add and push the new env via amplify cli, the same file changes occur, and connecting the new branch in the Amplify console results in a separate app talking to the correct backed, with master left as-is. All good!

Here’s where I get confused: I now want to merge develop to master.

If I do this, the aforementioned file changes will overwrite those in master, and I fear this will cause master to talk to the wrong back-end.

If I’m incorrect about this assumption, and checking these env related changes, please set me straight. I’m asking because, I’ve recently had an incident where I’ve deployed a front-end and it was talking to an incorrect back-end, but I’m not completely sure how exactly I worked that piece of magic.

If what I’ve described is correct, what is the workflow to be used to ensure that the correct cloud formation templates are committed to the correct branches so that deployment front-ends are configured with the correct back-ends?

[kevcam4891]

1. We’re working on a better way to do this - but at this point this is the way we’re handling uploading updates to the Lambda function via CloudFormation.

@kaustavghosh06 Have you guys had any progress on this? Is this a matter of ignoring the cloudformation file when doing the directory change hash computation, or something a little more nuanced?

[kaustavghosh06]

@kimfucious Yup, adding those files to .gitignore to avoid the headache of viewing it in git updates is a good idea if you’re not actively working on the resource. Closing this issue and goes without saying that if you have any other specific issues please feel free to open up a new issue in our repo!