Option to store .chalice/deployed folder in S3

[danil-smirnov]

It would be great to have an option to store .chalice/deployed/ folder content in S3 instead of locally. This will make teamwork easier without need to add this folder into source control.

[stealthycoin]

Yes I want this as well!

[wollerman]

Because this is specifically for this issue, I'll reiterate my comment from #972 here:

I was thinking something similar to how terraform can use a s3 remote backend. This way, you can specify a backend parameter in the config.json which points to a particular s3 location and allows you to deploy that configuration. e.g.

{
"stages": {
    "dev": {
      "api_gateway_stage": "api",
      "backend": {
        "location": "s3",
        "bucket": "mybucket",
        "key": "path/to/my/key",
        "region": "us-west-2",
     }
   }
  }
}

-or-

{
"stages": {
    "dev": {
      "api_gateway_stage": "api",
      "backend": {
        "location": "local"
     }
   }
  }
}

As a reference, here's terraforms documentation: https://www.terraform.io/docs/backends/types/s3.html

This would mean the configuration from any client is stored in a global location accessible to anything from other teammates to CI/CD jobs.

Terraform also has some more involved functionality to provide a lock via dynamo, but even having the deployed in s3 would be useful!

[snowman2]

After thinking about it, I think it would sense to add an aws s3 sync --delete source destination before and after the chalice command (switching source and destination where appropriate). This way it is only called on deployments and not locally without mixing the two in the config file.

[kislyuk]

I would really like to see this or other remote storage options (like Secrets Manager or Parameter Store). It's getting really old to either have to check in the folder (and tie the app repo to its deployment in one specific account) or have to instrument the handling or discovery of existing deployments when they happen from CD or from multiple workstations. This is a constant source of friction when adopting Chalice for new projects.

[vfilimonov]

It's a great suggestion, @snowman2 !

While it is not in implemented in chalice, I'm using the following Makefile: https://gist.github.com/vfilimonov/0bb4898463e0db02366173f5cd8ad416

.PHONY: deploy delete sync-state-up sync-state-down

deploy:
    @make sync-state-down
    chalice deploy --stage dev; make sync-state-up

delete:
    @make sync-state-down
    chalice delete --stage dev; make sync-state-up

sync-state-up:
    aws s3 sync --delete .chalice/deployed s3://S3.CONFIG.BUCKET/chalice

sync-state-down:
    aws s3 sync --delete s3://S3.CONFIG.BUCKET/chalice .chalice/deployed

So then instead chalice deploy and chalice delete I do make deploy and make delete - and the state is synced from/to S3 before/after the deploy.

And further I put deployed folder to .gitignore