search

aws-amplify / amplify-cli

The AWS Amplify CLI is a toolchain for simplifying serverless web and mobile development.
Apache License 2.0
2.81k stars 821 forks source link

RFC – CI/CD workflows and Multiple Environments as a part of Amplify CLI #286

Closed kaustavghosh06 closed 5 years ago

kaustavghosh06 commented 5 years ago

Feature Request

We would like to better support workflows around deployment and CI/CD in the Amplify CLI, as well as allowing you to use the configuration in multiple environments (DEV/TEST/STAGING/PROD etc).

Let's use this ticket to track the progress of this feature. We hope this will address some concerns in the following issues:

https://github.com/aws-amplify/amplify-cli/issues/128 https://github.com/aws-amplify/amplify-cli/issues/106 https://github.com/aws-amplify/amplify-cli/issues/197 https://github.com/aws-amplify/amplify-cli/issues/80 https://github.com/aws-amplify/amplify-cli/issues/166 https://github.com/aws-amplify/amplify-cli/issues/244

As part of this work we would like to capture your feedback in this issue. Please comment with your ideal workflow either for an individual or a team. Additionally, the following are starting point questions to help guide your responses:

Please comment with any additional thoughts not covered in the above list. Thank you.

JustFly1984 commented 5 years ago

1 - Yes, we are managing front-end and backend as separate git repos. 2 - Deploy would be a hard question. Since we do not deploy frontend to S3 but to netlify, and trying to be serverless, I see some real issues if I would need to deploy both at the same time. Sometimes we do not touch lambdas months, while making changes to frontend. 3 - Separate deployment stages are mandatory. 4 - Versions. if new frontend build fails with exit code > 1 - netlify just leaves current deploy as is. If we are talking about backend - new lambda does not override old one is good rule. Versions is the key. 5 - The ability to clone a backend is important, but nothing stops me to do it now, and hope will not in the future. If it will be automated somehow, will be a plus. Also I think it is important to mention about cases when we make similar product and sell it to our clients by deploying the project to their AWS account. 6 - Currently we are using react-static or gatsby to build app to static files and deploy frontend separate from backend. Deploying backend separate from frontend allows me to bring new programmers onboard, without warring about security more than I need to. If we could build our frontend to both, static AND serve-rside render on same CDN and same domain name, that would be a miracle!

7 - Not at this point.

8 - orchestration tooling - for lambdas - claudia.js, for frontend - github + netlify

9 - If two projects belongs to the same client/aws account - we can reuse some lambdas for several websites, otherwise no.

10 Git - yes!

11 - just support will be great for beginning. Pipeline should be optional.

12 === 8

PS: One more thing I forgot to add - we are keeping production on separate AWS account if DynamoDB involved.

hisham commented 5 years ago

  1. Currently new project and backend is in same repo, but considering portion of backend atleast in different repo especially if I use a different tool to manage parts of the backend such as SAM since Amplify CLI does not do everything we need in the way we need it yet. Have not decided yet.

  2. I think it's better to manage them separately. Reduces risk. If a change only affects the frontend then why redeploy the backend.

  3. Separate deployment environments for testing necessary but deployments do not necessarily need to go through any formalized approval / staging process.

  4. Rollbacks: I like the concept of blue/green deployments. So if a deployment fails you switch to the previous production environment. Also, with AWS, there is no "one" backend really. Your backend can consist of AppSync and Lambdas. The Lambdas can be treated differently then AppSync so you can have more fine-grained deployments and therefore rollback is easier.

  5. Clone a backend: Yes I think this is important so developers don't step over each other's toes. Especially with AppSync, it's very hard to clone AppSync backend if you are not using amplify cli and you set it up through the web console. Perhaps I can try to use CloudFormer to create it's CloudFormation and then clone it that way, have not tried that yet.

  6. SSR/NextJS: No.

  7. VPC: No.

  8. Relatively new project but have been using CloudFormation so far.

  9. Currently only have one frontend and if I have multiple frontends would want to use one backend.

  10. Yes using git.

  11. Support for different environments for cloning/testing purposes is all I need right now.

  12. CloudFormation so far.

austinamorusocfc commented 5 years ago
CodySwannGT commented 5 years ago
  • Are you managing frontend and backend code in the same repo? Yes. We have a few projects that use Amplify, AppSync and also Serverless Framework. Typically our directory structure looks like this:

Project Root -- client --- amplify -- server -- .git

  • Do you want to deploy your frontend and backend code simultaneously, or separately (e.g. manage as a single unit or separate entities)

Separately. Again, due to the shortcomings with Amplify, we have to supplement it with Serverless Framework.

$ serverless deploy #deploy some of backend

$ amplify push #deploy some of backend

$ amplify publish #deploy front end

  • Are separate deployment stages (approvals, canaries, etc.) important or mandatory?

Important

  • How would you like to handle rollbacks if a deployment of the frontend or backend fails?

It depends on what the failure was. We've seen a couple amplify push/publish fail and simply retrying fixed it.

  • Do you require the ability to clone a backend (within a team) and maintain separate environments (not necessarily deployment stages)

We use separate AWS accounts for each environment. Cloning across them is not necessary.

  • Are you using (or planning) an intermediary build tool for Server Side Rendering (SSR) such as NextJS?

One of our sites using Gatsby which builds the site prior to running amplify publish

  • Does your backend need to mix publicly exposed assets (e.g. websites) with private infrastructure in a VPC?

Some do. Some don't

  • Which cloud orchestration tooling are you using i.e. CloudFormation, TerraForm, or ServerLess?

Well, at the end of the day, serverless basically just is CloudFormation with niceties around it. Same with Amplify, so we use both of these and rarely touch CloudFormation directly.

  • Are you using the same backend for managing multiple frontend projects which use different frameworks?

No.

  • Are you using git to manage your projects? If not, what are you using for version control?

Yes. Git with CodeCommit

  • What is your team’s branching model w.r.t. working on features? (e.g. create feature branches, push to mainline directly or does every developer forks repos?)
$ git checkout -b <issue-number>
$ #work work work
$ git add .; git commit -am “closes <issue-number”
$ git checkout master
$ git merge <issue-number>
$ ## repeat on more issues throughout the iteration
$ ## increment appropriate version number in info.plist
$ cd client/ios 
$ fastlane beta
$ git tag -a <version-number> -m "version <version-number>"
$ git push origin <version-number>
$ ### when ready, deploy to App Store using fastlane or manually through App Connect
  • Do you want deployment pipeline support or just support for different environments for cloning/testing purposes?

Deployment pipeline support

  • Which cloud orchestration tooling are you using right now i.e. Cloudformation, Terraform, or Serverless?

Well, at the end of the day, serverless basically just is CloudFormation with niceties around it. Same with Amplify, so we use both of these and rarely touch CloudFormation directly.

thaerlabs commented 5 years ago

Hello everyone, I’d like first of all to thank the awsmobile/amplify team for their efforts in developing this project. It’s a breath of fresh air for mobile/web devs that want simplicity and power.

We started months ago using the awsmobile-cli and we’re now migrating to the amplify-cli to catch up on the new features, and till now multiple envs has been a real problem.

Are you managing frontend and backend code in the same repo?

Currently we’re using a monorepo structure, where we have a web package for the Vue frontend with the awsmobile project, and a backend package which is a collection of services using the serverless framework, it contains lambda functions listening to DynamoDB Streams, SQS Resources and other things happening behind the scenes

Do you want to deploy your frontend and backend code simultaneously, or separately (e.g. manage as a single unit or separate entities)

awsmobile-cli already has the -f flag, we’re using it when we have frontend only changes already

Are separate deployment stages (approvals, canaries, etc.) important or mandatory?

Indeed mandatory, at least separating Dev and Prod

How would you like to handle rollbacks if a deployment of the frontend or backend fails?

The way lambda handles versioning of functions and aliases is beatiful. Would be nice seeing the same approach for amplify stacks

Do you require the ability to clone a backend (within a team) and maintain separate environments (not necessarily deployment stages)

Not strictly required, but it would be nice if each team member could have his own clone stack to develop in isolation the features, not deployment stage, they would be separate instances of the same stage

Are you using (or planning) an intermediary build tool for Server Side Rendering (SSR) such as NextJS?

Not at the moment

Does your backend need to mix publicly exposed assets (e.g. websites) with private infrastructure in a VPC?

Not at the moment

Which cloud orchestration tooling are you using i.e. CloudFormation, TerraForm, or ServerLess?

We’ve been using the serverless framework. We were also taking in consideration the aws-cdk to manage custom parts to the stack to read config from the amplify project and connect custom parts of the backend, for generating couldformation templates

Are you using the same backend for managing multiple frontend projects which use different frameworks?

Not at the moment. But it’s a requirement for the future of our platform to have multiple frontends to use the same backend, for example and Vue web dashboard and a React Native mobile app

Are you using git to manage your projects? If not, what are you using for version control?

Yes git

What is your team’s branching model w.r.t. working on features? (e.g. create feature branches, push to mainline directly or does every developer forks repos?)

We are using Gitflow, create feature branches, work on them, and then PR to the target release branch

Do you want deployment pipeline support or just support for different environments for cloning/testing purposes?

Support for multiple envs atm is a more pressing topic than a deployment pipeline

joemastersemison commented 5 years ago

Our answers:

Are you managing frontend and backend code in the same repo?

Yes, monorepo with three React apps and two Appsync APIs, with all resolvers/lambdas/deployment config in it.

Do you want to deploy your frontend and backend code simultaneously, or separately (e.g. manage as a single unit or separate entities)

Simultaneously

Are separate deployment stages (approvals, canaries, etc.) important or mandatory?

Would love to do canaries, but hopefully can do with Route 53 weighted DNS.

How would you like to handle rollbacks if a deployment of the frontend or backend fails?

Ideally we have weighted DNS, separate deploy locations, and so the weight to the new deployment is just never set above 0.

Do you require the ability to clone a backend (within a team) and maintain separate environments (not necessarily deployment stages)

I think cloning is a bad process and you should really just have everything in a repo that you can issue a command to deploy somewhere else. Cloning indicates that you have poor automated deployments.

Are you using (or planning) an intermediary build tool for Server Side Rendering (SSR) such as NextJS?

No.

Does your backend need to mix publicly exposed assets (e.g. websites) with private infrastructure in a VPC?

No, so far successfully avoiding VPC and have absolutely no desire to get into that mess. We actually use a service called QuotaGuard to get a static IP to go out on for some APIs we need to call so that we can avoid VPC. I view VPC as an unnecessarily brittle and expensive element to most serverless architectures.

Which cloud orchestration tooling are you using i.e. CloudFormation, TerraForm, or ServerLess?

Current a home-grown script (~500 lines) that makes AWS CLI calls, but seriously investigating Stackery now that it has Appsync support, in which case we'd be in CloudFormation land.

Are you using the same backend for managing multiple frontend projects which use different frameworks?

Yes, for multiple React apps and also a React Native mobile app (this is in a separate repo) that is both Android and iOS.

Are you using git to manage your projects? If not, what are you using for version control?

Yes, GitHub.

What is your team’s branching model w.r.t. working on features? (e.g. create feature branches, push to mainline directly or does every developer forks repos?)

We branch on every ticket, with a rule for no long-lived branches and frequent synchronization of trunk back to branches. Trunk is locked, so you must pass all automated tests + code review + static analysis within GitHub and the merge to trunk through GitHub after all has passed.

Do you want deployment pipeline support or just support for different environments for cloning/testing purposes?

Would like to have prod deploy running the same stuff used for deploy everywhere--seems dumb to have a separate set of code/service for that.

Which cloud orchestration tooling are you using right now

Same answer as above; looking to Stackery, but current homegrown on AWS CLI calls.

mwarger commented 5 years ago

Are you managing frontend and backend code in the same repo?

Yes, for amplify. I do have a separate serverless backend that is a separate repo.

Do you want to deploy your frontend and backend code simultaneously, or separately (e.g. manage as a single unit or separate entities)

Simultaneously is fine.

Are separate deployment stages (approvals, canaries, etc.) important or mandatory?

Important, yes. Would love this to be close to serverless model, e.g. use an environment flag (--stage=dev) to push to certain environments based on variables and/or aws profile.

How would you like to handle rollbacks if a deployment of the frontend or backend fails?

Keep the last version out there.

Do you require the ability to clone a backend (within a team) and maintain separate environments (not necessarily deployment stages)

This would be helpful, but not necessary to begin with.

Are you using (or planning) an intermediary build tool for Server Side Rendering (SSR) such as NextJS?

No.

Does your backend need to mix publicly exposed assets (e.g. websites) with private infrastructure in a VPC?

No.

Which cloud orchestration tooling are you using i.e. CloudFormation, TerraForm, or ServerLess? Serverless for a separate backend consisting of lambdas.

Are you using the same backend for managing multiple frontend projects which use different frameworks?

Not currently, but this is something I would like to revisit in the future.

Are you using git to manage your projects? If not, what are you using for version control? Yes.

What is your team’s branching model w.r.t. working on features? (e.g. create feature branches, push to mainline directly or does every developer forks repos?)

We feature branch of develop and merge back when complete. Merge to master when needed.

Do you want deployment pipeline support or just support for different environments for cloning/testing purposes?

Integration with something like codepipeline would be great. But different environments would be a good start to begin with.

Which cloud orchestration tooling are you using right now i.e. Cloudformation, Terraform, or Serverless?

Cloudformation via Serverless Framework

marcelo-schroeder commented 5 years ago

I've just learned how to use the Amplify CLI, and have been playing with auth and api. It is really a powerful CLI and make things for developers with not much AWS experience like me really easier. However, I think one thing would be worth exploring, is to decouple the managing of backend resources from the integration with the app (I have been trying it out with React Native). I think that will also make it easier to integrate multi environment features into the CLI. This will also make it easier to have different apps using the same API. Also, one common thing to do is to have different versions of the app (i.e. different bundle ID's) for different environments (e.g. dev, UAT, SIT, prod).

jimbol commented 5 years ago

Are you managing frontend and backend code in the same repo?

Yes

Do you want to deploy your frontend and backend code simultaneously, or separately (e.g. manage as a single unit or separate entities)

Simultaneously

Are separate deployment stages (approvals, canaries, etc.) important or mandatory?

Mandatory, I cannot develop code in the same environment as production

How would you like to handle rollbacks if a deployment of the frontend or backend fails?

If possible, automatic rollback to the previous version. Additionally, being able to just override the current production version with the code from a previous git sha or git branch would be ideal.

Do you require the ability to clone a backend (within a team) and maintain separate environments (not necessarily deployment stages)

If two developers are working on the back end at once, then yes, they need to be able to develop in parallel.

Are you using (or planning) an intermediary build tool for Server Side Rendering (SSR) such as NextJS?

No

Does your backend need to mix publicly exposed assets (e.g. websites) with private infrastructure in a VPC?

Possibly

Which cloud orchestration tooling are you using i.e. CloudFormation, TerraForm, or ServerLess?

Currently using awsmobile, I'm wondering if I need to switch back to Serverless.

Are you using the same backend for managing multiple frontend projects which use different frameworks?

Not yet

Are you using git to manage your projects? If not, what are you using for version control?

Yes, github

What is your team’s branching model w.r.t. working on features? (e.g. create feature branches, push to mainline directly or does every developer forks repos?)

Feature branches

Do you want deployment pipeline support or just support for different environments for cloning/testing purposes?

If I could easily spin up N environments from the cli that would solve for both scenarios.

Which cloud orchestration tooling are you using right now i.e. Cloudformation, Terraform, or Serverless?

Still on awsmobile, so I guess Mobilehub. Thinking about switching to Serverless though for a more mature system

dguisinger commented 5 years ago

I've just learned how to use the Amplify CLI, and have been playing with auth and api. It is really a powerful CLI and make things for developers with not much AWS experience like me really easier. However, I think one thing would be worth exploring, is to decouple the managing of backend resources from the integration with the app (I have been trying it out with React Native). I think that will also make it easier to integrate multi environment features into the CLI. This will also make it easier to have different apps using the same API. Also, one common thing to do is to have different versions of the app (i.e. different bundle ID's) for different environments (e.g. dev, UAT, SIT, prod).

I agree, there are good ideas in the platform, it's just too tightly coupled. Because Amplify CLI can't work with existing resources, I took a good idea (the amplify config file) and modified my Terraform script to output a config file to the website S3 bucket whenever resources change... so at least the Amplify library can load the config and it works great.

I really wish that Amplify CLI had an option to not get involved with resource creation at all. There are a lot of assumptions being made in the GraphQL transforms that I'm not happy with... I have a region / country table for example, where I manually tuned it for combining two datasets in a single table, and my resolvers could pull back data in various ways depending on the way it was wired up. There's no way to do that from the new method.... connections seems to take over GSI creation, I don't even know if you can do LSIs. It would be nice if I could just point Model at an existing DataSource, and not have any resource creation happen at all. (My API, API Key, and DataSources are built by my backend terraform script, whereas my schema and resolvers are created by a parameterized cloudformation script that ask for the API ID and expect datasources of certain names).... Same with searchable, great idea, but do all models show up in the same ElasticSearch cluster? Is that even controllable? Can i tweak the cluster or am I stuck with their default settings? What if I wanted my trigger on one table to send data to multiple places, not just elasticsearch...... This level of automation is great for those who want it, and I can find it to be a definite time saver for them.... but as soon as you cross into something the tool can't do or want to manage part of it externally, because Amplify CLI requires management of everything, you have to abandon the tool... I really hope they change direction because I had high hopes for this tool, and so far I've only found confusion and disappointment.

joemastersemison commented 5 years ago

To add to what Dan is saying here--I am actually a strong proponent of tightly coupling the front end and back end, even with multiple front ends, but I wholeheartedly agree with Dan's request to have much better fine-grained control over resource creation and connection.

A parallel I see here is with Angular, where things are just too "magical"--you don't know exactly what's happening or why, and you can't control it. The primary reason why I switched my teams to React is because you do have that fine-grained control, and nothing is magic. I think in order for Amplify to be truly successful, it needs to take the magic out.

On Sun, Oct 14, 2018 at 1:04 PM Dan Guisinger notifications@github.com wrote:

I've just learned how to use the Amplify CLI, and have been playing with auth and api. It is really a powerful CLI and make things for developers with not much AWS experience like me really easier. However, I think one thing would be worth exploring, is to decouple the managing of backend resources from the integration with the app (I have been trying it out with React Native). I think that will also make it easier to integrate multi environment features into the CLI. This will also make it easier to have different apps using the same API. Also, one common thing to do is to have different versions of the app (i.e. different bundle ID's) for different environments (e.g. dev, UAT, SIT, prod).

I agree, there are good ideas in the platform, it's just too tightly coupled. Because Amplify CLI can't work with existing resources, I took a good idea (the amplify config file) and modified my Terraform script to output a config file to the website S3 bucket whenever resources change... so at least the Amplify library can load the config and it works great.

I really wish that Amplify CLI had an option to not get involved with resource creation at all. There are a lot of assumptions being made in the GraphQL transforms that I'm not happy with... I have a region / country table for example, where I manually tuned it for combining two datasets in a single table, and my resolvers could pull back data in various ways depending on the way it was wired up. There's no way to do that from the new method.... connections seems to take over GSI creation, I don't even know if you can do LSIs. It would be nice if I could just point Model at an existing DataSource, and not have any resource creation happen at all. (My API, API Key, and DataSources are built by my backend terraform script, whereas my schema and resolvers are created by a parameterized cloudformation script that ask for the API ID and expect datasources of certain names).... Same with searchable, great idea, but do all models show up in the same ElasticSearch cluster? Is that even controllable? Can i tweak the cluster or am I stuck with their default settings? What if I wanted my trigger on one table to send data to multiple places, not just elasticsearch...... This level of automation is great for those who want it, and I can find it to be a definite time saver for them.... but as soon as you cross into something the tool can't do or want to manage part of it externally, because Amplify CLI requires management of everything, you have to abandon the tool... I really hope they change direction because I had high hopes for this tool, and so far I've only found confusion and disappointment.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/aws-amplify/amplify-cli/issues/286#issuecomment-429643248, or mute the thread https://github.com/notifications/unsubscribe-auth/AFVdBYxL5RyM-u9rhKP2NeLyHLeXVHrMks5uk26agaJpZM4XOHQ1 .

undefobj commented 5 years ago

@dguisinger @joemastersemison a couple of comments:

Please remember this is an RFC for CI/CD workflows in the CLI core. There are some comments here made around using the GraphQL transformer (which is a library in the package) for specific DynamoDB controls like indexes. Feature requests around that are best made as new issues in the repo otherwise we will not be able to track them and get feedback. This RFC is for more than just GraphQL but overall category workflow requests.

Amplify isn't trying to be "magical" with anything, though we are trying to be opinionated with default implementations while giving you flexibility to take things into your own control. That's true of not only the CLI but also toolchain features (like writing your own transformer) and the library. It's a very hard design challenge to keep things simple while still allowing for flexibility when advanced customers wish to perform additional actions. That's the point of the RFC, to see what new controls need to be introduced. I would also note that you're going to see some new documentation in the next week that not only talks about how the entire CLI works under the covers with CloudFormation and metadata, but also outlines how to author your own plug-in as an effort for transparency.

Existing resources - this is an item on our roadmap: https://github.com/aws-amplify/amplify-cli/issues/288 https://github.com/aws-amplify/amplify-cli/issues/174 Amplify CLI is using CloudFormation under the covers, there are technical aspects to doing this action with existing resources which must be designed. Please comment on those issues with some of your requirements. If you are trying to use existing resources within a CI/CD flow as sort of a "mix and match" scenario, please comment here in this RFC.

I understand that you might be trying to look for more flexibility. The project is only about 6 weeks old and there is much room for improvement in the future. Amplify is focused on making the job of mobile and web developers easier when working with cloud services. Many customers don't want to know all the details of distributed systems and cloud infrastructure, which is what motivates many designs for simplify at an attempt to not leak implementation into the abstractions. For certain customers the existing experience is ideal while for others there is still more work to do.

dguisinger commented 5 years ago

@undefobj I'll take my response private, but I do feel knowing how your customers want to automate their flow is actually a important part of understanding CI/CD needs. But your points are understood.

undefobj commented 5 years ago

to have much better fine-grained control over resource creation and connection.

@joemastersemison could you elaborate on this with specific use cases? We're looking at a few things here but getting the proper scope in your workflow would be helpful. Thanks.

joemastersemison commented 5 years ago

@undefobj -- here are a couple examples:

undefobj commented 5 years ago

Thanks @joemastersemison this is good information. We're actually working on the 4th bullet now: https://github.com/aws-amplify/amplify-cli/issues/74

Interestingly from the list the DynamoDB streams and Lambda policies are in a way related. We might be able to pull that apart into a primitive. cc @kaustavghosh06

cbernardes commented 5 years ago

Quick note:

nicosommi commented 5 years ago

Are you managing frontend and backend code in the same repo? In some projects we do, but most of them are in separate repos.

Do you want to deploy your frontend and backend code simultaneously, or separately (e.g. manage as a single unit or separate entities) It makes sense to do both together as a unit, however I don't know until which point will that be possible... with complex fastlane-like distribution setups with different os, stores, context setups, etc.

Are separate deployment stages (approvals, canaries, etc.) important or mandatory? Important

How would you like to handle rollbacks if a deployment of the frontend or backend fails? Usually rollbacks are very particular to the transaction to be rolled back, so as long as there is a way to do it, it would be nice enough for us.

Do you require the ability to clone a backend (within a team) and maintain separate environments (not necessarily deployment stages) No, at least no yet

Are you using (or planning) an intermediary build tool for Server Side Rendering (SSR) such as NextJS? No

Does your backend need to mix publicly exposed assets (e.g. websites) with private infrastructure in a VPC? Not yet but possibly in the future

Which cloud orchestration tooling are you using i.e. CloudFormation, TerraForm, or ServerLess? None yet (well amplify cli), if we do add one, I will probably go with Terraform.

Are you using the same backend for managing multiple frontend projects which use different frameworks? We will probably do this at some point, but not now.

Are you using git to manage your projects? If not, what are you using for version control? Yes we use git.

What is your team’s branching model w.r.t. working on features? (e.g. create feature branches, push to mainline directly or does every developer forks repos?) Master branch with feature branches and PRs, tags for releases and maybe an extra develop / staging branch, no forks.

Do you want deployment pipeline support or just support for different environments for cloning/testing purposes? Right now we need a clear path/guideline for code sharing and CI workflow. A couple of docs and a some polish to a .gitignore will be good enough for now I believe.

Which cloud orchestration tooling are you using right now Same as above. None (just amplify cli). In the future probably Terraform.

ahmetcetin commented 5 years ago
brianhilst commented 5 years ago
xzilja commented 5 years ago

Are you managing frontend and backend code in the same repo? Yes

Do you want to deploy your frontend and backend code simultaneously, or separately (e.g. manage as a single unit or separate entities) Separate entities

Are separate deployment stages (approvals, canaries, etc.) important or mandatory? Yes

How would you like to handle rollbacks if a deployment of the frontend or backend fails? Roll back backend individually using amplify cli

Do you require the ability to clone a backend (within a team) and maintain separate environments (not necessarily deployment stages) Yes

Are you using (or planning) an intermediary build tool for Server Side Rendering (SSR) such as NextJS? Yes

Does your backend need to mix publicly exposed assets (e.g. websites) with private infrastructure in a VPC? Yes

Which cloud orchestration tooling are you using i.e. CloudFormation, TerraForm, or ServerLess? CloudFormation, default created by amplify cli

Are you using the same backend for managing multiple frontend projects which use different frameworks? Yes

Are you using git to manage your projects? If not, what are you using for version control? Yes, using git

What is your team’s branching model w.r.t. working on features? (e.g. create feature branches, push to mainline directly or does every developer forks repos?) master as main branch, feature branches that go into it. Releases are cut via tagging master.

Do you want deployment pipeline support or just support for different environments for cloning/testing purposes? Both ideally

Which cloud orchestration tooling are you using right now i.e. Cloudformation, Terraform, or Serverless? Cloudformation

pigmanbear commented 5 years ago

Are you managing frontend and backend code in the same repo?

Yes

Do you want to deploy your frontend and backend code simultaneously, or separately (e.g. manage as a single unit or separate entities) Ability to Choose

Are separate deployment stages (approvals, canaries, etc.) important or mandatory?

Yes

How would you like to handle rollbacks if a deployment of the frontend or backend fails?

Previous Version

Do you require the ability to clone a backend (within a team) and maintain separate environments (not necessarily deployment stages)

Yes

Are you using (or planning) an intermediary build tool for Server Side Rendering (SSR) such as NextJS?

No

Does your backend need to mix publicly exposed assets (e.g. websites) with private infrastructure in a VPC?

Yes

Which cloud orchestration tooling are you using i.e. CloudFormation, TerraForm, or ServerLess?

All 3, focus on CloudFormation and TerraForm

Are you using the same backend for managing multiple frontend projects which use different frameworks?

Not currently.

Are you using git to manage your projects? If not, what are you using for version control? Yes

What is your team’s branching model w.r.t. working on features? (e.g. create feature branches, push to mainline directly or does every developer forks repos?)

Feature branches

Do you want deployment pipeline support or just support for different environments for cloning/testing purposes?

support for different envs primarily, pipeline support would be a nice to have

Which cloud orchestration tooling are you using right now i.e. Cloudformation, Terraform, or Serverless? All 3, focus on the first 2

dacz commented 5 years ago

Are you managing frontend and backend code in the same repo?

no. Our GraphQL endpoint is separate stack managed by serverless.

Do you want to deploy your frontend and backend code simultaneously, or separately (e.g. manage as a single unit or separate entities)

generally no, but can imagine cases, when yes.

Are separate deployment stages (approvals, canaries, etc.) important or mandatory?

Noce to have.

How would you like to handle rollbacks if a deployment of the frontend or backend fails?

If fails, it will not be deployed.

Do you require the ability to clone a backend (within a team) and maintain separate environments (not necessarily deployment stages)

no strong opinion

Are you using (or planning) an intermediary build tool for Server Side Rendering (SSR) such as NextJS?

not now, but the requirement is practical.

Does your backend need to mix publicly exposed assets (e.g. websites) with private infrastructure in a VPC?

Yes. But we manage this by separate stacks.

Which cloud orchestration tooling are you using i.e. CloudFormation, TerraForm, or ServerLess?

serverless.com

Are you using the same backend for managing multiple frontend projects which use different frameworks?

currently yes (backend serevrless.com, frontend amplify)

Are you using git to manage your projects? If not, what are you using for version control?

git

What is your team’s branching model w.r.t. working on features? (e.g. create feature branches, push to mainline directly or does every developer forks repos?)

branches, merge requests and deploy if ok

Do you want deployment pipeline support or just support for different environments for cloning/testing purposes?

we need deployment pipeline support

Which cloud orchestration tooling are you using right now i.e. Cloudformation, Terraform, or Serverless?

serverless.com

mkrn commented 5 years ago

Are you managing frontend and backend code in the same repo? Ideally not, perhaps with amplify in very small projects it could be the same repo. But most of the time there would be several web or web+mobile applications for same backend.

Do you want to deploy your frontend and backend code simultaneously, or separately (e.g. manage as a single unit or separate entities) Separate entities

Are separate deployment stages (approvals, canaries, etc.) important or mandatory? No

How would you like to handle rollbacks if a deployment of the frontend or backend fails? Similar to cloudformation

Do you require the ability to clone a backend (within a team) and maintain separate environments (not necessarily deployment stages) Yes. It would be great to be able to clone it to a different account, etc.

Are you using (or planning) an intermediary build tool for Server Side Rendering (SSR) such as NextJS? No

Does your backend need to mix publicly exposed assets (e.g. websites) with private infrastructure in a VPC? No

Which cloud orchestration tooling are you using i.e. CloudFormation, TerraForm, or ServerLess? CloudFormation

Are you using the same backend for managing multiple frontend projects which use different frameworks? Yes

Are you using git to manage your projects? If not, what are you using for version control? Yes git

What is your team’s branching model w.r.t. working on features? (e.g. create feature branches, push to mainline directly or does every developer forks repos?) Feature + PR to master

Do you want deployment pipeline support or just support for different environments for cloning/testing purposes? Different environments

Which cloud orchestration tooling are you using right now i.e. Cloudformation, Terraform, or Serverless? Cloudformation

mkrn commented 5 years ago

Right now testing if Amplify CLI could actually replace our existing CI/CD cloudFormation stack that worked like this:

So far most of the features are there, except:

Now with those the CI process would be simple: create CodePipeline with pull, build and run amplify push in buildspec.yaml

rriveras commented 5 years ago
kevinwolfcr commented 5 years ago

Thanks for making this RFC! 🙌🏻 🙏🏻

Are you managing frontend and backend code in the same repo?

No, right now we haven't been able to start using amplify backend features since it does not handle stages yet, so we have the following repos:

Do you want to deploy your frontend and backend code simultaneously, or separately (e.g. manage as a single unit or separate entities)

Separately, since they live on different repos, we have CircleCI configurations for each one.

Are separate deployment stages (approvals, canaries, etc.) important or mandatory?

Mandatory

How would you like to handle rollbacks if a deployment of the frontend or backend fails?

For frontend we don't need to rollback since if the build (lint, tests) fails, then the deployment won't happen.

On the backend side, we run unit tests on a test environment, which uses @gopato/serverless-plugin-dynamodb-jest (soon to release!) and if tests fails, then deployment won't happen.

Do you require the ability to clone a backend (within a team) and maintain separate environments (not necessarily deployment stages)

As we are using dynamodb-local, when a dev clones the project and runs setup, they will have a dynamodb local server for test/dev.

Are you using (or planning) an intermediary build tool for Server Side Rendering (SSR) such as NextJS?

Not right now, the only web application we maintain it's a dashboard, so it's a SPA.

Does your backend need to mix publicly exposed assets (e.g. websites) with private infrastructure in a VPC?

No.

Are you using the same backend for managing multiple frontend projects which use different frameworks?

Same backend, but all projects use React.

Are you using git to manage your projects? If not, what are you using for version control?

Yes.

What is your team’s branching model w.r.t. working on features? (e.g. create feature branches, push to mainline directly or does every developer forks repos?)

On front end apps, we create a branch from master, dev and make a PR. The PR get's deployed to an isolated URL on web (thanks, Netlify) or a release channel (thanks, Expo).

For the backend I haven't set up the workflow yet, but ideally we want to have same behavior.

Do you want deployment pipeline support or just support for different environments for cloning/testing purposes?

Different environments.

Which cloud orchestration tooling are you using i.e. CloudFormation, TerraForm, or ServerLess?

Serverless Framework.

lahirian commented 5 years ago

It would be good to have a CLI option in amplify to recreate the resources (i.e. cognito user pool or dynamodb ) in case they are inadvertently deleted. This is specially true for test environment where resources get cleaned up automatically.

Also I think the simplest and consistent way would be replicate the "profile" feature of AWS config file in the Amplify CLI config file to support multiple profiles.

benbayard commented 5 years ago

Are you managing frontend and backend code in the same repo?

All BE code is on the appsync console right now. However, our entire project is 1 codebase

Do you want to deploy your frontend and backend code simultaneously, or separately (e.g. manage as a single unit or separate entities)

Separately

Are separate deployment stages (approvals, canaries, etc.) important or mandatory?

neither.

How would you like to handle rollbacks if a deployment of the frontend or backend fails?

Rollback to a specific commit

Do you require the ability to clone a backend (within a team) and maintain separate environments (not necessarily deployment stages)

Tihs would be incredibly useful for multiple engineers

Are you using (or planning) an intermediary build tool for Server Side Rendering (SSR) such as NextJS?

No.

Does your backend need to mix publicly exposed assets (e.g. websites) with private infrastructure in a VPC?

No

Which cloud orchestration tooling are you using i.e. CloudFormation, TerraForm, or ServerLess?

Cloudformation (really just the amplify cli)

Are you using the same backend for managing multiple frontend projects which use different frameworks?

No

Are you using git to manage your projects? If not, what are you using for version control?

Git!

What is your team’s branching model w.r.t. working on features? (e.g. create feature branches, push to mainline directly or does every developer forks repos?)

PRs in to master. Typically small standalone PRs

Do you want deployment pipeline support or just support for different environments for cloning/testing purposes?

I want N development environments + Prod. A staging would be nice as well

Which cloud orchestration tooling are you using right now i.e. Cloudformation, Terraform, or Serverless?

Cloudformation. Really just the amplify CLI.

michaelcaterisano commented 5 years ago

Are you managing frontend and backend code in the same repo?

Yes, I'm using the amplify code that is generated by amplify init and storing the amplify/ in my React project's root directory, on the same level as my src/ directory.

Do you want to deploy your frontend and backend code simultaneously, or separately (e.g. manage as a single unit or separate entities)

I'm currently deploying them simultaneously using amplify publish, but I can imagine it would be nice to separate the backend code and deploy it separately.

Are separate deployment stages (approvals, canaries, etc.) important or mandatory?

Not currently.

How would you like to handle rollbacks if a deployment of the frontend or backend fails?

Rollback to most recent depoloyment.

Do you require the ability to clone a backend (within a team) and maintain separate environments (not necessarily deployment stages)

Yes

Are you using (or planning) an intermediary build tool for Server Side Rendering (SSR) such as NextJS?

Not on my current project, but I would like to be able to use Next.js for future projects.

Does your backend need to mix publicly exposed assets (e.g. websites) with private infrastructure in a VPC?

No

Which cloud orchestration tooling are you using i.e. CloudFormation, TerraForm, or ServerLess?

I'm using Amplify with AppSync, which I think uses CloudFormation by default.

Are you using the same backend for managing multiple frontend projects which use different frameworks?

Yes, I am planning to build a React Native client to go along with my React web client, and would like to use the same backend for both.

Are you using git to manage your projects? If not, what are you using for version control?

Yes, using git

What is your team’s branching model w.r.t. working on features? (e.g. create feature branches, push to mainline directly or does every developer forks repos?)

Check out feature branch -> do work -> merge commits to master branch

Do you want deployment pipeline support or just support for different environments for cloning/testing purposes?

Both would be nice

sravimohan commented 5 years ago
stevelizcano commented 5 years ago

Are you managing frontend and backend code in the same repo? Same repo, but one for React, and another with React Native.

Do you want to deploy your frontend and backend code simultaneously, or separately (e.g. manage as a single unit or separate entities) Simultaneously but accessed from a web app, and another repo with the react native app.

Are separate deployment stages (approvals, canaries, etc.) important or mandatory? No, not yet.

How would you like to handle rollbacks if a deployment of the frontend or backend fails? Some sort of versioning system would be good, to roll back to prev. cloudformation templates.

Do you require the ability to clone a backend (within a team) and maintain separate environments (not necessarily deployment stages) YES!

Are you using (or planning) an intermediary build tool for Server Side Rendering (SSR) such as NextJS? No

Does your backend need to mix publicly exposed assets (e.g. websites) with private infrastructure in a VPC? Yes

Which cloud orchestration tooling are you using i.e. CloudFormation, TerraForm, or ServerLess? CF

Are you using the same backend for managing multiple frontend projects which use different frameworks? Yep, React and React Native using the same Auth and AppSync backends, analytics etc.

Are you using git to manage your projects? If not, what are you using for version control? Git.

What is your team’s branching model w.r.t. working on features? (e.g. create feature branches, push to mainline directly or does every developer forks repos?) Mainline.

Do you want deployment pipeline support or just support for different environments for cloning/testing purposes? Support for different environments and front ends, and syncing updates between them is super important.

Which cloud orchestration tooling are you using right now i.e. Cloudformation, Terraform, or Serverless? CF

kaustavghosh06 commented 5 years ago

Based on all of your feedback, we’ve released a beta version of the CLI (npm install -g @aws-amplify/cli@multienv) to support multiple environments, team workflows and integrate with your CI/CD flows. Please check out this documentation for more details - https://aws-amplify.github.io/docs/cli/multienv?sdk=js Also, as a part of our feedback mechanism, we’ve opened up another GitHub issue, to track feedback from everyone, iterate on this beta version and then merge it to master. We'll close this issue and track feedback in #508. Looking forward to your feedback on this release.