Open SeanBannister opened 6 years ago
Thanks for the feedbacks @SeanBannister
What you guys are doing is correct in terms of how collaborations on a project should be done using awsmobile-cli.
For the newly added appsync feature, you can do a comparison on the corresponding contents in the #current-backend-info
folder and thebackend
folder to see how the awsmobile-cli is striping away deployment specific data.
Could you please be more specific on what files in /awsmobilejs/backend/
contains deployment specific data for your project? and what is the deployment specific data in them?
Sorry about the late response, bouncing between projects.
To easily show you an example I've forked the aws-amplify-graphql repo, run the steps in the readme which deploy it to AWS and then pushed the changes back to the repo.
In particular take a look at:
/awsmobilejs/backend/appsync/dataSources.json {suffix}
gets replaced by a generated suffix that's specific to the deployment.
/awsmobilejs/backend/mobile-hub-project.yml name: photo-client
gets replaced with whatever the developer decides to call their development deployment which will most likely be different to the production deployment name.
There's a few other files that get deployment specific data, you can see them in the full commit.
{suffix} was put there to avoid name clashes during table creations, and those files can be manually edited before awsmobile push
is executed. awsmobile-cli will not modified the contents if there are no placeholder strings such as {suffix} or {managed-by-awsmobile-cli}.
DynamoDB table names are only unique within a region and within each individual aws account. You can certainly put the {suffix}
back if you want the cli to generate a random string in that place.
@UnleashedMind have you (or anyone) been able to find documentation related to placeholder strings such as {suffix} or {managed-by-awsmobile-cli}? it seems awsmobile overwrites a lot of parameters across various files and it would be nice to know which those are.
@SeanBannister thanks for insight into your Amplify workflow in an 2+ member team. Do you guys have a dev/staging/production environment that you switch between or are all constantly working in the prod environment?
@gentleShark Unfortunately we don't have any documentation on that. Currently the appsync feature is incomplete with awsmobile-cli.
@SeanBannister what did your team end up doing? I am facing the same dilemma in terms of version control for the awsmobile/backend folder
Initial project is on hold but we ended up determining awsmobile wouldn't give us enough flexibility and considered using https://serverless.com instead.
On Mon, Sep 17, 2018, 10:16 AM scrapex notifications@github.com wrote:
@SeanBannister https://github.com/SeanBannister what did your team end up doing? I am facing the same dilemma in terms of version control for the awsmobile/backend folder
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/aws/awsmobile-cli/issues/108#issuecomment-421858197, or mute the thread https://github.com/notifications/unsubscribe-auth/AAMCb9eCEvT9gPPgZpb1fKt77qvWyWuBks5ubunhgaJpZM4TbK0r .
We use
awsmobile-cli
in our daily development workflow, we store all our AWS Mobile Hub configuration data in/awsmobilejs/backend/
so that when a new developer comes on board they clone our repo, typeawsmobile init --yes
and have a new dev environment up and running. Currently our biggest problem is how to version control/awsmobilejs/backend/
in git.Take for example one of the default AWS sample repos aws-samples/aws-amplify-graphql, as soon as you run
awsmobile init --yes
some of the files in/awsmobilejs/backend/
get a very small amount of deployment specific data added to them. Obviously we don't want to commit this deployment specific data to git because each developer has a separate dev environment and therefore these files conflict.We can't add the files to
.gitignore
because.gitignore
only works for files that aren't currently in version control. We tried using git's--skip-worktree
and--assume-unchanged
but these options only apply locally and can't be committed to the repo.Ideally the initial configuration files used by
awsmobile init --yes
would be stored separately from the environment specific changes so we could use .gitignore.Or maybe we're missing something?