Delivery Readiness: Preparing your team for Chef Delivery [feedly]

----
Delivery Readiness: Preparing your team for Chef Delivery
// Chef Blog

Yesterday we held a webinar on Delivery Readiness: Preparing your team for Chef Delivery. We briefly defined Continuous Delivery, talked about the values that CD adds to an organization and how Chef Delivery fits in that picture. The focus of the webinar was on common criteria that emerged among our first set of Chef Delivery customers.

Some of those patterns will be familiar to existing Chef users (e.g. local development), others are new prescriptions (e.g. use git and feature-branch model of software development). The webinar concluded with a 20-minute Q&A session that we've listed below. You can watch the full recording here:

For those interested in a more in-depth demo of Chef Delivery, reach out to your Chef rep or email awesome@chef.io . Delivery is currently available by invitation only. You can register at https://www.chef.io/delivery/ to receive updates as availability expands.

Q&A From the Live Webinar:

Q: Will Delivery also be open-source or an "enterprise" add-on?

A: Not open source but there are open source components: delivery-cli and delivery-truck (and we expect to open source other build cookbooks).

Q: Can you model your own pipeline template? You mentioned the pipeline was pre-built but what if you need to modify it?

A: No, the pipeline shape is fixed. But you define what happens at each phase within the pipeline – with chef DSL.

Q: Can you give us some more details about the delivery truck cookbook?

A: delivery-truck is a Chef Delivery build_cookbook for continuously delivering Chef cookbooks. You can find more information and download it here: https://github.com/opscode-cookbooks/delivery-truck

Q: Assuming the misc parts mentioned here for local ++ jenkins build/coordinater testing upstream from local to "staging/etc", what do you recommend preparing for the next pieces in the pipeline?

A: Use delivery-cli and delivery-truck.

Q: Does Chef Delivery have anything to do with with actually applying changes to servers (aka converges)? If not, is it suggested to do converges manually or automatically using chef-client in daemon mode? Which way is suggested and how fast will it be to deliver a fixed version of a cookbook using chef-delivery? I'm assuming a bad cookbook passed all the tests, but still fails the production because of some bad logic.

A: User defines what happens in the deployment phase. User can decide to trigger a chef-client run on all nodes affected by a change or just publish to a chef server.

Q: Will Chef Delivery work across multiple organizations (such as separate dev/cte/production orgs)?

A: Absolutely. Delivery includes an enterprise/organization/project structure.

Q: Can Chef Delivery support pipelines where some of the steps (for instance part of the testing) is manual?

A: Delivery deploys artifacts associated with a change into an acceptance environment, runs automated tests to verify the deployment as well as additional automated integration tests. Delivery waits here for the user to click the Deliver button. Manual user acceptance testing can therefore take place in the acceptance environment prior to hitting the Deliver button.

Q: Does Chef Delivery work with static system reservations for different projects?

A: Not sure what the question is exactly. You can interact with other systems if they have APIs and thus could arrange for "checking out" infrastructure to run tests or deployments. For example you can deploy to a container management solution like kubernetes in this fashion.

Q: What happens if the chef server is unavailable?

A: Builds won't run because the build nodes won't be found since we query the chef server for build nodes.

Q: What are the programming languages Chef supports?

A: Chef supports all the programming languages.

Q: Is Chef Delivery designed to replace existing build tools like Jenkins?

A: Jenkins is awesome at executing jobs but doesn't know about workflow. Delivery is also great at running jobs but the real challenge is not running jobs, it's managing the workflow. Users can integrate delivery with Jenkins if needed but not necessarely.

Q: How does Chef Delivery handle multi-node orchestrated deployments?

A: Users can define what happens in the deployment phase using code. Users can create logic in the build recipe, call external services, etc.

Q: You're recommending git as the version control. We are currently using subversion. Is there any reason why we couldn't use subversion with Chef Delivery?

A: Delivery requires Git at the moment. We are looking at integrating with other SCM options in future versions of the product.

Q: Can you explain a bit more the idea of one cookbook per repo?

A: Each individual cookbook should be stored in their respective repositories instead of having a repository for all cookbooks with a "cookbooks" directory that contains all cookbooks. This makes it easier to keep track of changes and share.

Q: On-prem includes open-source server?

A: Delivery is not open source and requires use of Chef Server v12 (with a Chef subscription).

Q: How do you do local or automated tests on code that relies on being in a real environment, with real infrastructure such as, say, EBS volumes in a certain configuration? I find that automated testing sounds great in theory, but in practice does not work.

A: If you need to test on EBS you need to run your code on EBS. But usually it is not required to test code on EBS unless your code interacts with the EBS functionality. In most cases testing your app in a VM or container on local host should be fine – in respect to disk… Unless you are specifically testing disk performance and reliability.

Q: The 6 stages of continous delivery pipelines happens in hours, days, weeks?

A: The duration of moving a change through the pipeline depends on how long it takes to execute the code in the recipes. In most use cases it takes minutes – unless you are building environments from sources – in this case, there would be upfront time of however long it takes to build the environment and then however long it takes to run the code.

----

Shared via my feedly reader

Sent from my iPhone