CloudBees is growing and as part of our business growth, we found that we needed to overhaul and rebuild our corporate website. In keeping with our DNA, we wanted to do this in a continuous fashion to ensure resilience, find defects early and reduce overall risk at launch time.
We decided to move away from our old content management system (CMS) which was better suited for a smaller company to a more robust, modern CMS, Contentful, that gives us more enterprise capabilities like finely-tuned access controls that allow designated CloudBees employees to edit the web content they own directly. Bee-ing a team at CloudBees meant we also wanted to do this in a continuous fashion with a modern pipeline. Website launches are almost always a “big bang” release with a lot of effort focussed on a perfect reveal. But that’s not how CI/CD best practices are written and certainly not in keeping with progressive delivery. Understandably, our marketing team was a little worried, what about SEO and the impression a un-finished product might have if someone sees it? We knew these were real concerns but still wanted to find a way to quickly deliver new updates and features without holding out for perfection.
How could we do both? Then in a divinely inspired act of ‘eating our own granola’, we decided to use feature flags. With the new website available behind a feature flag, our authentication system could tell us if a logged-in user was an employee. Using that segmentation criteria we used CloudBees Rollout feature flags to enable what would be the production website. This way internal stakeholders could keep track of what was happening and the team was able to deploy to production.
So how do we deploy to production at CloudBees?
Our CI/CD is based on CloudBees Core, where our Jenkins pipeline runs at every commit. A pull request only gets merged if approved by at least one other engineer and if all steps in Jenkins were successful. Some of our most important steps are:
- TypeScript code compilation
- Linter rules check
- Unit tests
- Creation of the docker image
- Apply migrations to our Contentful model
- Tests against the docker image and the Contentful environment
At every merge on our master branch, a new build is run and code is automatically deployed to our staging environment. Because of the numerous in-depth changes made daily to the website codebase, we decided to have an engineer checking the state of staging daily and, when OK, triggering the production deployment (all done within CloudBees Core of course!).
We could have done this without any human interaction but it would have required a heavy investment in automated testing which would have made little sense while iterating so quickly between marketing, design and the engineering team.
While Jenkins was running dozens of builds every day, the general public was only able to view a few pages made of a handful of UI components and could barely notice any change. However, every logged-in CloudBees employee was able to witness our progress and give feedback in real time in Slack. No VPN necessary, no magic URL. All done with a simple CloudBees Rollout feature flag:
Things we learned
It’s always important when eating your own granola to keep track of the things that were harder than expected. During this project we learned a few things that are actively becoming part of our product roadmap.
- It was hard to keep track of work that was and was not behind the feature flag.
- For the website it was hard to determine the flow of code / features and the flow of content. We were copying production to staging for content but code went from staging to production.
- With only local development, a staging environment and production environment some members of the team could not really view design changes
The most boring go-live (in the best way).
On November 25th the new CloudBees.com website went live. Seamlessly, quietly, uneventfully and without the explosions that sometimes accompany ‘Big Bang’ deployments. Just exactly like we planned.