Note: steps use the v3
of the Azure DevOps Chef Extension.
Azure DevOps Pipelines YAML templates for common steps and stages, as well as examples of usage in complete pipelines in the example_pipelines
directory for:
- Cookbook CI (with a Policyfile for dependency resolution only, instead of Berksfile)
- Prep:
- Git tag for version in
metadata.rb
does not exist yet - Cookbook
metadata.rb
:- Lists at least one supported platform
- Specifies a Chef Version
- Any dependencies are pinned using
~>
pessimistic (or=
equality) version constraints
- Git tag for version in
- Lint:
- Cookstyle
- ChefSpec
- Integration Testing:
- kitchen-azure
- kitchen-vsphere
- Release:
- Git Tagging with version in
metadata.rb
- Git Tagging with version in
- Prep:
- Policyfile CI/CD
- Including promotion using Azure DevOps Environments mapped to Chef Infra Server Policy Groups
- Prep:
- Update Policyfile Lock JSON (
chef install
andchef update
) - Publish updated Policyfile Lock JSON as pipeline artifact
- Update Policyfile Lock JSON (
- Integration Testing:
- kitchen-azure
- kitchen-vsphere
- Publish:
- Export Policyfile archive (
chef export -a
) - Publish updated Policyfile Lock JSON as build artifact
- Export Policyfile archive (
- Release/Deploy:
- Use
deployment
jobs withenvironments
mapped to policy groups and push Policyfile archive to Policy group (chef push-archive
)
- Use
# A name that describes what the system you're building with Chef does.
name 'test-policy'
# Where to find external cookbooks:
default_source :supermarket
# run_list: chef-client will run these recipes in the order specified.
run_list 'test::default', 'chef-client::default', 'audit::default'
# Specify a custom source for a single cookbook:
cookbook 'test', git: 'https://AZUREREPOHERE/_git/test', tag: 'v0.1.8'
default['development']['test']['message'] = 'test message for development'
default['production']['test']['message'] = 'test message for production'
The Policyfile CI/CD pipeline also works with Policyfiles that use include_policy
from another repo (by automatically commiting the Policyfile Lock JSON so it's available for other policies to include) e.g.
# This is the file server policy for all Chef managed file servers.
name 'another-policy'
# Where to find cookbooks:
default_source :supermarket
# include base policy
include_policy 'test-policy', git: 'https://AZUREREPOHERE/_git/test-policy', path: 'test-policy.lock.json'
# Chef-client will run these recipes in the order specified.
run_list 'openssh::default'
example_pipelines
directory also includes legacy workflow pipelines for:
-
Chef Repo CI/CD (environment, roles, data bags)
- Lint:
- JSON Lint
- Legacy Workflow safety checks including:
- Every cookbook listed in environment files is pinned with equality
=
pin - Every cookbook version listed in environment files exists on the Chef Infra Server
- Every environment file pins every uploaded cookbook
- Every cookbook listed in environment files is pinned with equality
- Upload:
- Upload Roles, Environments and Data Bags
- Lint:
-
Cookbook CI/CD (with Berksfile)
- Prep:
- Git tag for version in
metadata.rb
does not exist yet - Cookbook or cookbook version has not been uploaded to the Chef Infra Server organisation yet
- Cookbook
metadata.rb
:- Lists at least one supported platform
- Specifies a Chef Version
- Any dependencies are pinned using
~>
pessimistic (or=
equality) version constraints
- Publish Berksfile Lock as pipeline artifact
- Git tag for version in
- Lint:
- Cookstyle
- ChefSpec
- Integration Testing:
- kitchen-azure
- kitchen-vsphere
- Release:
- Berks Upload
- Git Tagging with version in
metadata.rb
- Prep: