Continuous Integration and Delivery - chef-boneyard/chef-summit-2014 GitHub Wiki

Thursday, Issaquah, 2:30

I don't know?

A full house in Issaquah

Most people talked about examples of pipelines, and the different problems they solve.

• Every cookbook has a rake file, each cookbook developer can make rake do whatever they want. It is the cookbook maintainer's responsibility to make sure the cookbook is tested.
  • You know the CD pipeline will do the same thing your machine will when you run rake
  • It is a simple interface
  • Can use custom generators and templates to create the rake file with suggested defaults, like test-kitchen, rubocop, etc.

• Every dev is responsible for testing their code locally before pushing to git, and the build system is responsible for making sure that many people's code changes work together (integration testing), and then it is responsible for testing different environments.
  • Test on the feature branch and then test on master after the feature branch is checked in.
  • Code reviews must pass before the branch can be merged to master.
• A good way to get started is to write a simple pipeline that uploads anything that comes to it. Then you push all your code through this pipeline, and start expanding the pipeline to match your testing requirements.
  • If you cannot build your tests into your source code, you won't be able to build a pipeline that runs these successfully (?)

Nordstrom has the app developers write their own cookbooks. Their CD team provides office hours to app teams, reviews their cookbooks, publishes best practices and tooling. The cookbook request workload is too much for 3 maintainers to support, so they have to push it to the app teams and support them.

• Use chef to manage your CI agents, and then use that CI system to promote the cookbook and converge the agents.
  • One person codified their Jenkins jobs, so each developer runs a Jenkins instance locally and uses that to test their CI pipeline each time. Meta.
  • Build your Jenkins in such a way as you can restore it from a backup and continue building/deploying from where it died.
  • Jenkins Job DSL Plugin is a plugin that spits out a DSL which Jenkins uses to create jobs (see also JUC - Berlin: Configuration as Code: The Job DSL Plugin). Then you can store the DSL in each git repo and use Chef to auto-generate Jenkins jobs.
• Create your CI builders using chef ahead of time, don't try and introspect a submitted build job to determine what builder it needs and then create that builder.

• Caching artifacts locally is good, it saves time
• @echohack described the 3 ways of deploying code to the chef server
  • Use Berkshelf to pin cookbook versions to an environment, can upload cookbooks to the server without affecting existing environments. This allows maintenance windows.
  • Regulatory environment - production has to be firewalled from the internet. Use Berkflow to package complete artifacts that can then be deployed to different environments. These artifacts can run chef solo.
  • FB way - 'we scale so much, so fuck it, just push it to prod'. There is no versioning in environments on the chef server, and no environments. They just push changes to a percentage of nodes and test to make sure it still works there.
• Avoid having CI jobs and other post-commit systems that modify source and commit back to the repo. 'Everything should only go 1 way - Like food'

This can provide an example of different ideas for CI/CD pipelines. One of the points we talked about is how every environment has different deploy artifacts and requirements, so there is no silver bullet. But many people used Jenkins (even if they didn't like it).