Custom Aliases in Your Continuous Delivery Pipeline

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