Freigeben über

Continuous Deployment to Azure Automation DSC Part 2

  • Artikel

This is a continuation from the post here where I created a build and release pipeline for my DSC configurations. This post looks at attaching some process around when a build and release should be completed.

I've used my dev branch in Git for a development build and the master branch for a production release. This means that when someone changes the dev branch a build will be automatically triggered and same for the master branch. To do this I had to perform a couple of steps for the build process. Aside from renaming to make more sense - I basically cloned the existing build process and modified it for the master branch.

snip_20170412103822

Each branch has a trigger set on it to perform a build when the corresponding branch is updated...

snip_20170412103918

I also create a production artifact now - this allows me to trigger a release when a new artifact is created.

snip_20170412103935

I created a new script to be added to this artifact for the production release. It does exactly the same as the dev one however uses a different path (different artifact path generated). I want to later on be able to update the development process to be able to release a dev DSC configuration which won't affect my production machines.

snip_20170412104454

Doing that takes care of the build process - now for the release. Aside from some cosmetic changes it is exactly the same as the development release process however I updated the script to be the ReleasePROD.ps1 file.

snip_20170412103822 snip_20170412103918 snip_20170412103935

All tested and working after a couple of minor changes - but now I have a process as follows, VSTS allows me to lock down my branches in source control so I can control who can merge.

  1. User creates a new branch and adds/updates a configuration.
  2. They submit a pull request to add their changes to the dev branch (they don't have permissions to modify dev)
  3. I approve the pull request and the build to dev is triggered.
  4. If it passes I can then trigger a dev release which uploads and compiles the configuration. I still need to find a way to mark a configuration as a dev configuration so it doesn't change production nodes.
  5. When this is all done and tested - I can submit a pull request to pull the dev branch into master.
  6. Once approved it will trigger a build for production - the generated artifact then triggers a release into production.

So my process is coming together - next steps are to refine and separate the configurations between development and production. Of course this still for configurations that have no external resources or credentials - that is going to add a new layer of complexity.