DEV Community

If you use Amplify and Git branches, you are going to have a bad time

Yonatan Korem on June 07, 2022

AWS Amplify is... A combination of tools that aim to assist with development, deployment, and hosting of your serverless application. A...
Collapse
 
danrivett profile image
Dan Rivett

Great article, you concisely explained the exact reason why we have always avoided the workflow Amplify advocates under their Team environments page.

We've instead kept the concerns of Amplify environments and git code branches separate to avoid running into the issues you outline. We haven't unfortunately solved the CI/CD dance yet as each developer manages their own Amplify backend, but we've at least avoided the issues you outline above.

I'm not sure why the categories data in team-provider-info.json needs to be stored separately per environment under source control. There must be a good reason, but seems like there's a better way to avoid all this pain.

Collapse
 
yonatankorem profile image
Yonatan Korem

Hi Dan,

First, thanks for the feedback.

We also just can't figure out why the team-provider-info.json works like that. It'll be interesting to hear the actual reasons.

Can you further explain your workflow? Each dev works on their own environment, but how do you merge changes into the main environment?

Collapse
 
jhachtel profile image
Jeff Hachtel

Amplify helped us get an app up and running in a very short time. We took that route because integrating auth was so easy, then found out how easy everything else was - until it wasn't. We abandoned Amplify and took another route for exactly the reasons you highlight here.

Collapse
 
yonatankorem profile image
Yonatan Korem

Hi Jeff,

That is exactly what happened with us. Authentication was a big selling point for us since we not only set up Cognito with Amplify CLI, but also used the Amplify React library that provides a login screen that fully integrates with Cognito.

It is incredible what you can achieve in one hour with Amplify. But after one month, you'll find it is more of a hinderer.

Collapse
 
peibolsang profile image
Pablo Bermejo

Great, great, article

Collapse
 
conorw profile image
Conor Woods

I'm not sure i fully understand the issue.
If the amplify/backend/backend-config.json file is saved in git, does this file determine what resources are deployed, not the "categories" portion of the team-provider-info.json file?

Collapse
 
yonatankorem profile image
Yonatan Korem

Hi Conor,

From my understanding, which is based on Amplify failing to deploy and figuring out how to fix it, part of what happens is based on team-provider-info.json file.

If you add an environment variable to a lambda, the files within the lambda directory will say something that translates to "this lambda is expecting to have an environment variable named X".
But, the value of it is defined in the team-provider-info.json file, under the key that matches each environment. That is how Amplify allows you to set different values for the same variable, per environment.

When you add an environment variable, it does not automatically appear in all environments, only in the one you are currently on.
If you commit that file and try to build a different environment based on your git content, it will fail.

Same goes for any resource that you add or remove.

Collapse
 
conorw profile image
Conor Woods

thanks yonathan, the difference in setups must be that I am currently not using env variables.

I got so frustrated with having to set the env variables per lambda function that I now deploy my SSM independently from amplify and share them with all the lambda functions.

Thread Thread
 
yonatankorem profile image
Yonatan Korem

The same happened when we added lambdas. If your backend definition, which is environment agnostic, defines something which is not included in the relevant environment entry in team-provider-info.json, then when you try to deploy it will fail.

Thread Thread
 
conorw profile image
Conor Woods • Edited

I think my setup might be slightly different as I'm not seeing the same issue.

To compare, here are the steps I take to create and deploy a project:

  • I create dev, test, prod envs (in separate AWS accouts) and check in the team-provider-info file to git.
  • The CICD (github actions) kicks off when the dev branch is changed and deploys to dev + test
  • A merge to main kicks off a prod deploy.
  • The CICD checks out the repo, npm i, amplify init (i use an init.sh file for this, see below), amplify push

If i create a new function in dev and merge to main, it creates the new function OK in the prod env, even though the team-provider file remains the same in git.

`#!/bin/bash
set -e
IFS='|'

AWSCLOUDFORMATIONCONFIG="{\
\"configLevel\":\"project\",\
\"useProfile\":false,\
\"profileName\":\"default\",\
\"accessKeyId\":\"${AWS_ACCESS_KEY_ID}\",\
\"secretAccessKey\":\"${AWS_SECRET_ACCESS_KEY}\",\
\"region\":\"us-east-1\"\
}"
AMPLIFY="{\
\"projectName\":\"projname-server\",\
\"envName\":\"${ENV}\",\
\"defaultEditor\":\"code\"\
}"
FRONTEND="{\
\"frontend\":\"ios\"
}"
PROVIDERS="{\
\"awscloudformation\":$AWSCLOUDFORMATIONCONFIG\
}"
CODEGEN="{\
\"generateCode\":true,\
\"codeLanguage\":\"typescript\",\
\"fileNamePattern\":\"graphql/*/.graphql\",\
\"generatedFileName\":\"API.ts\",\
\"generateDocs\":true,\
\"maxDepth\":2\
}"
AUTHCONFIG="{\
\"appleAppId\":\"${AMPLIFY_APPLE_ID}\",\
\"googleAppIdUserPool\":\"${AMPLIFY_GOOGLE_CLIENT_ID}\",\
\"googleClientId\":\"${AMPLIFY_GOOGLE_CLIENT_ID}\",\
\"googleAppSecretUserPool\":\"${AMPLIFY_GOOGLE_CLIENT_SECRET}\"
}"

CATEGORIES="{\
\"auth\":$AUTHCONFIG\
}"
amplify init \
--amplify $AMPLIFY \
--categories $CATEGORIES \
--frontend $FRONTEND \
--providers $PROVIDERS \
--codegen $CODEGEN \
--yes
`

Thread Thread
 
yonatankorem profile image
Yonatan Korem

First, nice job!

Second, I think what you've made is the custom CI/CD process that solves this problem because you also needed to have different environments on different accounts.

Thread Thread
 
conorw profile image
Conor Woods

Thank you, it took a lot of pain, frustration and searching through github issues to find that resolution.
I agree with your article: amplify sells a great story if you go down the happy path, but stray slightly, and you're left frustrated.

Collapse
 
oseh_mathias_d7ceced0302b profile image
Oseh Mathias

This is how I ended up doing it after 2 years of struggle

Have one branch where you check out to all of your amplify envs and push to them to keep them in sync

For me it's the dev branch

I'll build the dev API and resources, then when I'm happy, while still on the dev branch, amplify env checkout staging, amplify push --y, amplify env checkout main, amplify push --y

Then, you can merge the branches willy nilly and they'll always be in sync