Recommended workflow for team usage

[dan1elhughes]

We are building an app using AWSMobile & Amplify, in a team of 3-4 developers. There is one developer working on the backend stuff and the others are working on the frontend.

Therefore we need a way to be able to pull an existing project in order to get the aws-exports.js file so we can run the build. However, running an awsmobile init <project-id> in a build with an existing /awsmobilejs folder creates a new folder with the date in the filename, deletes most of what's in /awsmobilejs, and does not correctly link with the backend project. The pulled aws-exports.js file also does not include the required appsync data.

Is there a recommended way to work with awsmobile CLI as a team?

[UnleashedMind]

Thanks for your feedbacks. Without the appsync feature, the recommended workflow is what you are doing, init with a mobile hub project id would pull down access information of a mobile hub project. The folder with the timestamp is meant to backup your work. Unfortunately, the integration with appsync is incomplete at this moment. The appsync feature is not part of a mobile hub project. So the normal workflow of init with <project-id> is not going to work with the appsync feature.

[AustinDeric]

+1 this request! Also, if I may add a team workflow request for a staging (sometimes called development) and production setup for those of us using CI/CD.

Right now i manually have 2 projects: 1 for staging and 1 for production. They share a user pool. When i push to a staging branch, i would like to deploy (with environment variables #139) to a staging mobile hub project. And when i push to a master branch i would like to deploy to the production mobile hub project.

[swaminator]

@AustinDeric: I'm the PM for Mobile Hub. Would love to chat with you 1:1 to share plans. Can you share your email address with me? (If you prefer, DM me on Twitter @TheSwaminator)

[AustinDeric]

@swaminator more than happy to! Austin.Deric@gmail.com

Maybe this description will help. I think that by implementing #139 would allow for CI/CD (https://docs.gitlab.com/ee/ci/pipelines.html) and solve this issue. And documentation.

The workflow (as also described in the link above and is typical for DevOps) would be:

1. developer '2' makes code changes, commits code then makes pull/merge request.
2. developer '1' reviews code changes and merges PR into master branch which kicks-off the CI/CD process.
3. the pipeline, using environment variables, would then issue the awsmobile publish command. The only thing that may be nessesary is an 'example' .gitlab-ci.yml or .travis.yml file (i have these if you need).

[swaminator]

Great.. I just emailed you. Look fwd to chatting!

[stevenpovlitz]

edit: We removed mobilehub from the application and replicated all resources we needed in CloudFormation. CF is awesome for solving this issue, don't know why mobilehub doesn't integrate with it.

@swaminator Our team of three RN developers have a slightly different way of provisioning resources, so each branch has its own set of backend resources, for a project with Dynamo, MobileHub, and AppSync.

0. awsmobile init --remove; git reset --hard - ensures only the aws files that are NOT gitignored are in the project.

1. Change values for tableName and TableName names in awsmobilejs/backend/appsync/dataSources.json to include{suffix}

2. In the same file, change the value for serviceRoleArn to {managed-by-awsmobile-cli}

3. awsmobile init --yes

4. awsmobile appsync configure

5. awsmobile push

6. In app/config/AppSync/index.js, edit value for graphqlEndpoint: to the link from the AppSync API just created, under API Details page on the console.

7. Make sure the auth method is properly permissioned. In the case of IAM, that means checking the policy attached to the Federated Identity Pool just created.

Its fairly manual process, and important to keep track of all resource names so one dev doesn't accidentally modify another dev's setup.

[eoliphan]

This is important for us as well. I think a good example would be the way Elastic Beanstalk works. A given version of your 'application' is pushed to basically a registry, and you have 1-n 'environments', where you would have your data sources, etc configured, to which you can deploy a given version of the application. That can accommodate pretty much any workflow.

[swaminator]

@eoliphan @stevenpovlitz you should check out the Amplify CLI which deploys resources using CloudFormation. We are also working on multiple environments, so let me know your email address and I can set something up.

[richardzyx]

@swaminator I work with Steven on the same team, my email: richard.zhang711@gmail.com and we'd love to hear more, thanks!

[jonmifsud]

@swaminator we're starting to get really deep into AWS Mobile as well with multiple projects and multiple developers. We're also trying to have centralised repositories pushing to multiple AWS accounts so I guess we'd have to work with cloud formation and can't really use the default awsmobile stack long term unless I'm missing something.

[dan1elhughes]

Looks like the Amplify CLI might deal with this, I'll have a go on that tool instead.

[swaminator]

The Amplify CLI now supports team workflows. If you're looking to use the Amplify CLI in conjunction with the Console, you can view the recommended workflow here: https://docs.aws.amazon.com/amplify/latest/userguide/multi-environments.html