For the past 10 years, I had the opportunity to work in various types of projects, in a number of industries. In that time I have developed some thoughts about software and the process of creating it.
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.
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.
For the past 10 years, I had the opportunity to work in various types of projects, in a number of industries. In that time I have developed some thoughts about software and the process of creating it.
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.
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.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:
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
`
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.
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.