Feature request: '--delete' option

[gburgett]

We have a need to backup the content from our production space, and import it into our testing space. We would like to do this regularly in order to test primarily our migration strategy when we deploy new code.

One option we have already explored is deleting our test space and then creating a new test space via an import. Unfortunately this means we have to update all our environment variables with the new space Id and access token, and it also destroys our webhooks.

We are primarily interested in copying over content types, content, and assets (just asset nodes, not uploading the assets themselves). The purpose of the proposed --delete option would be to remove all content types, content, and assets that do not exist in the imported data. Essentially, it would be equivalent to deleting all data in the space before running the import. However it would be faster and use fewer API calls because it could take the difference of all IDs existing in the space vs the IDs in the import, and only delete those.

Proposed example use cases:

# space 2xcd should be identical to space 1xab after this operation
contentful-export --space-id 1xab --content-file /tmp/export.json && \
  contentful-import --space-id 2xcd --delete /tmp/export.json

# does not delete any content types or locales regardless of what's in the json
contentful-import --delete --skip-content-model contentful-export-1xab-2018-01-01.json

# copies over and synchronizes only content types, content and assets, not roles or webhooks
contentful-export --skip-webhooks --skip-roles  --content-file /tmp/export.json && \
  contentful-import --delete /tmp/export.json

[floelhoeffel]

Hey gburget,

Thanks for the suggestion! We are currently testing a new feature on the backend which will make it very easy to clone content into environments. This should hopefully address you usecases too so you don't need to move entire spaces entry by entry around through tooling. We are aiming for a public release soon and I'd like to ask you for a little patience - it's worth it.

Thanks,
Frederik

[gburgett]

Thanks! Exactly what we were looking for

[gburgett]

@floelhoeffel I have another question maybe you could answer re: the environments API.

Currently our migration strategy involves running the migration-cli at the same time that we release our new code. Unfortunately, possibly due to edge caching, the newly created links are not available on the CDN for anywhere from 5-30 seconds after the migration is run. We're investigating doing zero-downtime deployments by cloning a space, running our migrations, then swapping out the environment variable which determines the space our app points to.

Would environments provide an alternative to this? Is there some atomic swap command or another way we could version our environments to do zero-downtime releases?

Thanks!

[floelhoeffel]

I am not really sure on the final answer to this due to the ongoing development on the feature. I think aiming for the ParallelChange pattern might be good.

https://martinfowler.com/bliki/ParallelChange.html

• Content (and editors) to always stay in the master environment (prod)
• for breaking changes you branch environments of prod and test your new migration (script driven) in the env
• once happy with the result, the migration is applied to master (following an expand and contract pattern)

In the initial release, it wont be possible to promote non-master envs into master.

cc @benben @thebiglabasky

[gburgett]

Thanks for the info! We actually just got an email from Ben inviting us to join the environments beta, which is awesome! We'll definitely take a look at making this work.