Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Custom Aliases in Your Continuous Delivery Pipeline

Custom Aliases in Your Continuous Delivery Pipeline

9155ebfc50776ca2d9327f2d0e7f9f47?s=128

Contentful Webinars

November 19, 2020
Tweet

More Decks by Contentful Webinars

Other Decks in Technology

Transcript

  1. Live Demo: Custom aliases in your continuous delivery pipeline 19th

    November 2020 1 Internal Use
  2. Housekeeping • This webinar will be recorded; we will share

    the recording and slide deck with all registrants shortly -- keep an eye on your inbox! • Please add your questions in the Q&A box, we will answer them after the presentation during the Q&A session at the end • To get in touch, get in touch on Twitter @contentful or write to us at team@contentfulmail.com Before we dive in...
  3. Introductions Shy Ruparel Developer Evangelist at Contentful Janko Marklein Software

    Engineer at Contentful
  4. This has a personal and a technical side. Let’s discuss

    the technical one! 4
  5. • Ship small changes • Deploy constantly • Rollback quickly

    if things break 5 DevOps practices
  6. To not be afraid of these practices, we need the

    right tooling
  7. Two parts of the deployment process make things especially difficult

    7
  8. • Not part of your version control setup • Changes

    can not be easily reverted • Often require some manual updating 8 1. Database and 2. CMS
  9. For databases • Write migrations and check them into your

    version control system • Use local containers and / or staging environments to test out structural changes before applying them to production data 9 So what to do about it?
  10. But how to make changes to your CMS less stressful?

  11. Let’s have a look at the tooling that Contentful provides

    for this. 11
  12. • Space Environments • Content Migrations • Environment Aliases 12

    Agenda
  13. One master environment (by default) • Serves as your production

    space • Used by editors /spaces/<space_id>/ /spaces/<space_id>/environment/master/ 13 Space Environments master
  14. master Copy this (or any other) environment to get a

    sandbox setup with the same content model as the master. /spaces/<space_id>/environment/<environment_id>/ 14 Space Environments local-sandbox-1 local-sandbox-2
  15. Want to try out a new feature that involves changes

    of the content model? • You don’t want to experiment with production content • So you spin up a new environment and use it for testing 15 How would you use them?
  16. Let’s see how you can create them in the Web

    App. 16 +
  17. 17 DEMO #1

  18. We can now test our content model independently of the

    production data. 18
  19. You have some nice options: • Quickly manually try out

    content model changes in a local setup Even nicer would be: • Set up a staging environment where you apply your content model changes before you apply them to the production space. • Make environments part of a CI/CD pipeline 19 Some use cases
  20. For setups like a staging environment or a CI/CD pipeline

    we need automation 20
  21. 21 • Apply programmatic content model changes • Similar to

    how you would write migrations to the structure of your database • Write your migrations in JavaScript or TypeScript What can you do with it? The migration tool
  22. 22 • Create content type • Delete content type •

    Edit content type • Create/edit/delete fields • Change field ID • Update content metadata (tags) Some Examples
  23. Running migrations Workflow example master staging ci Run migration scripts

    Run migration scripts Run migration scripts
  24. Let’s see a simple migration example in action. 24

  25. 25 DEMO #2

  26. 26 Using the migration tool and environments we can: •

    Write repeatable content model migrations and check them into version control • Easily test out any content model changes programmatically locally by using a personal sandbox environment • Set up a staging / QA environment or a CI/CD pipeline with a dedicated contentful environment
  27. This takes a lot of stress away from the deployment

    workflow, because it gives you confidence that content model changes won’t break things. 27
  28. But there are still some parts of the deployment process

    where things can go wrong. 28
  29. master staging ci Run migration scripts Run migration scripts Run

    migration scripts This still feels scary.
  30. There is no way to quickly rollback content model changes

    if things go wrong. 30
  31. 31 • An environment alias is a static identifier •

    You can think of it as a symlink pointing to a specified environment Environment aliases
  32. 32 • Once you opt in, you get a default

    “master” alias. • Instead of having a master environment, you now have a master alias that has a target environment. /spaces/<space_id>/environments/master /spaces/<space_id>/ Environment aliases
  33. Enabling environment aliases for a space By renaming master environment

    and adding an alias in its place release-1 master master
  34. master Point alias to any environment release-1 release-2 /spaces/<space_id>/environments/master

  35. 35 • Similar to the master environment the master alias

    has a special status • Create more aliases with custom ids if you want to • We are looking into renaming “master” to “main” A few things to keep in mind.
  36. Let’s create some aliases. 36

  37. 37 DEMO #3

  38. Now we have a way to deploy content model changes

    without running migrations against a live production environment. 38
  39. Minimize downtime and allow instant rollback master is no longer

    a stand-alone environment but acts as an alias targeting another environment Production content is served from release-1 environment Execute migration scripts Change master alias to target release-2 environment Production content is now served from release-2 environment Promote Problem discovered! Rollback is required Rollback Rollback master to target release-1 environment release-1 release-2 Use case: Promote an environment to master master
  40. Of course, this process can be adapted to different use

    cases. 40
  41. Better safe than sorry master is no longer a stand-alone

    environment but acts as an alias targeting another environment Content is served from prod environment Run migration scripts Restore by changing master alias to target prod-backup environment Backup Problem discovered! Rollback is required Restore prod prod-backup Use case: Backup and restore master Optional: Delete prod environment prod Optional: Recreate prod from prod-backup Change master alias to target prod environment
  42. 42 Sum up Integral parts of agile development now can

    be integrated into your workflow: Devs can feel safe about constantly shipping changes, because: • Flexible manual and automated testing can be done beforehand and as part of the deployment • Rollbacks are easy
  43. 43 Docs Tutorials: - Integrating migrations in a continuous delivery

    pipeline with CircleCI - Scripting migrations with the Contentful CLI Concepts: - Multiple environments - Environment Aliases
  44. 44 Docs Articles: - Keep your deployments on track: Contentful

    now has seamless promotion and rollbacks Code: - contentful/contentful-cli - contentful/contentful-migration
  45. Let’s see how this looks in a CI/CD pipeline 45

  46. 46 DEMO #4

  47. Source control Local computer 47 Dev writes code Merged into

    Master, Staging or QA via pull request Continuous Integration Provider Update alias to use newly created environment Deploys the new code PUSHED Hosting provider TRIGGERS A BUILD Stop the build Creates new environment and runs migration scripts on Contentful Run tests and checks DID THE TESTS PASS? YES NO
  48. 48 Q&A