Repeated merge conflicts due to multi-env workflow

Hello,

I am using amplify with multiple environments and a CI pipeline, and I am facing a specific problem. I am not sure whether this is due to a lack of understanding of the deployment process?

I have two environments, dev (development branch) and prod (master branch).

My workflow is as follows:

• on dev/development work on frontend/backend, push resources using amplify publish
• commit changes
• git checkout master && amplify env checkout prod
• git merge development
• amplify status shows me that I changed stuff and the backend will be updated
• amplify publish

This is all fine, the problem starts now:

When published on prod, there are file changes. The diff shows that the changes are only related to a key “Code” in the lambda functions’ cloudformation templates in the backend folder:

/amplify/backend/function/function_name/function_name-cloudformation-template.json

"Code": {
-   "S3Bucket": "app_name-20190716141290-deployment",
+  "S3Bucket": "app_name-20190716180513-deployment",
     "S3Key": "amplify-builds/function_name-ru14rdtn1erne110ne-build.zip"
}

In the docs, it is said that these files should be committed. However, when committing such changes, I repeatedly get a merge conflict when merging new changes from development because then master has already diverged.

I thought about storing the backend folder in an S3 bucket for dev and prod each to avoid this versioning problem, but I am not sure whether that’s intended.

What am I doing wrong?

[plaa]

@RossWilliams @kaustavghosh06 If those changes aren’t supposed to be committed, then Amplify should not make the changes. Amplify could make a temporary copy of the file and update that instead of editing the git version.

The whole issue is that Amplify is making changes into source files, which then manually need to be avoided. It’s a pain especially when editing the CF files (see my original comment).

Also not committing the files has the negative impact of having them be deployed every time even though nothing has changed.

[RossWilliams]

@chantlong This sounds correct, status is going to show function updates, and pushes are going to take a bit longer. I don’t commit the new keys in the way you describe mainly because our automated pipelines and policies don’t support it. If you have a production branch that you can commit to directly, your method does sound good.