So you want to move from agent based Release Management to vNext but still need Tokenization. 13 February 2015 Donovan-Brown Work (0) The xReleaseManagement resource brings Release Management Tokenization to Desired State Configuration. The xReleaseManagement resource enables a natural migration path from Agent Based Release Management deployments to DSC (or vNext) based deployments. This resource supports using the technique described in this blog post which uses the XML transform functionality of Visual Studio to create a tokenized version of the web.config. This technique does not require a .token file to be in the target folder. The resource can also be used by simply making a tokenized copy of your target file and adding a .token file extension. This resource is an official release of the resource I shared here back in September with some additional features. You can get the official resource from http://tinyurl.com/xReleaseManagement. If you have any questions feel free to contact me on twitter @DonovanBrown.
Toggle the Retain Indefinitely flag from Release Management 10 February 2015 Donovan-Brown Work (0) Problem:We employ continuous delivery with Release Management and our drop server has run out of di [More]
Release Management Comparison Chart 09 February 2015 Donovan-Brown Work (0) This blog post is comparing the current features set of Microsoft’s hosted Release Management solution – Release Management Online (RMO) and the on premises Release Management product. Feature Comparison (as of February 2015) On Premises RMO azure Desired state configuration PowerShell Custom tools Agent based only Agent based Trigger release from build Web approval on premises Users Groups Change Summary vNext only Pickup from drop share pickup from VSo There are a few other points to consider when deciding between on premises and RMO. First is the effort needed to trigger a release from a build. Granted both options support it but RMO supports this with no need for a custom build template or making REST API calls. It just works. There is also no server to install with RMO. RMO is a SaaS application hosted for you in the cloud by Microsoft. You simply install the WPF Client and connect to your RMO server.
My DSC works from PowerShell ISE but not from Release Management 06 February 2015 Donovan-Brown Work (0) If you are like me you learned Desired State Configuration (DSC) before trying to incorporate it with Release Management. I recommend this because you get a pure understanding of DSC and its full capabilities. The only caveat to learning DSC this way is certain things are different when used with Release Management. One of which came up today, which is the way we identify the nodes. Using pure DSC you have many choices on how you identify the nodes to target. You can use Configuration Data, hardcode the values or even parameterize your DSC script. However, I have had the most success when I use $env:COMPUTERNAME. You could also use 'localhost'. When you learn DSC outside of Release Management you use a developer workstation to create the MOFs and push them from there to the target nodes. However, when Release Management runs a DSC script it is first copied to the target machine. Then the script is executed to create the MOF file to be pushed to the node. Because the script is being copied to the target the use of $env:COMPUTERNAME eliminates the need to hardcode any values in your script and reduces the chance for error.
My vNext Release fails with SSL error 05 February 2015 Donovan-Brown Work (0) Problem: I am trying to deploy using Release Management vNext pipeline and I receive the following error: Connecting to remote server MyServer failed with the following error message : The server certificate on the destination computer (MyServer:5986) has the following errors: The SSL certificate is signed by an unknown certificate authority. For more information, see the about_Remote_Troubleshooting Help topic. Solution: Make sure you set the SkipCaCheck to true. This sets the value of the SkipCACheck parameter of the New-PSSessionOption cmdlet used to execute our PowerShell. When the value is true, the client does not validate that the server certificate is signed by a trusted certificate authority (CA) when connecting over HTTPS. SkipCaCheck was introduced in Windows PowerShell 2.0.
My Release Template changes are being ignored 04 February 2015 Donovan-Brown Work (0) I was recently asked for help with Release Management where the user noticed the changes to their Release Template were not taking effect. After further investigation I identified the confusion and felt it deserved further explanation. The user began a release which failed on a “Deploy Using PS/DSC” action. Based on the detailed log the user identified an error in their Release Template and corrected their mistake. They then returned to the failed release and clicked the “Retry Failed Deployment” button to retry the deployment. The release failed again in the exact same place as if the changes were ignored. The reason for the subsequent fail is because once a release is started a copy of the Release Template is made. Therefore, any changes to the Release Template will not affect any running releases. To see those changes the user would have to start a new release. However, there is a way to change the values used in a release that is already inflight. To change the values used in a Release Template for an active release you need to click “View Sequence” and make your changes there. Please note these changes only affect the release where the changes are made and do not change the Release Template the release was started from.
There appears to be a bug in the XCopy Deployer tool for Release Management 19 January 2015 Donovan-Brown Work (0) I was looking around on the User Voice page for Release Management and noticed a feature request about using /exclude flag with the XCopy Deployer tool. The user was requesting the tool be updated to support that option. My knee jerk reaction was just add a Custom tool yourself that does it! So that is exactly what I am going to show you how to do in this post. Instead of starting from scratch I thought I would leverage the work of the Release Management team and harvest the irxcopy.cmd file and see what they had done. You can see my previous post on how to harvest the out of box tool resources if you need help finding the irxcopy.cmd file. Once I had a copy of the file I noticed that the tool did appear to support the /exclude flag of xcopy. All the user has to do is provide a file named excludedfileslist.txt in the component's source folder. However, after some testing and further investigation it appears the irxcopy.cmd file has a bug that overwrites the original contents of the file instead of appending to it as intended. My original excludedfileslist.txt file is below. This is what it looks like after it is used with irxcopy.cmd. The irxcopy.cmd file contained the following commands. As you can see on line 3 the single greater than '>' should be a double greater than '>>'. The single is actually replacing all the contents with irxcopy.cmd instead of adding irxcopy.cmd to the end. We are going to write our own cmd file named myxcopy.cmd below. Now all we have to do is add it to the tools inventory and set our component to use our tool instead. Now our excludedfileslist.txt file looks correct and the xcopy excludes the desired files.
How to harvest the out of the box Agent Based tools from Release Management 19 January 2015 Donovan-Brown Work (0) One of the great features of Release Management is the ability to add your own custom tools. Many times the custom tool I want to add is similar to one of the tools that comes out of the box. Yet, there is no way from within Release Management to download the resources that make up the out of the box tools. However, during the execution of a release the Release Management Server copies all of the tools resource files to the agent machine. Therefore, all you have to do is create a Component that uses the desired Tool and search the agent machine for the resource name. For example let’s locate the irxcopy.cmd resource of the XCopy Deployer tool. First open a Command Prompt as Administrator. We need to run as Administrator so we can search user folders of other users. The files will be under the AppData folder of the user that the Microsoft Deployment Agent is running as. From the root of your system drive type: dir irxcopy.cmd /s This will search all the directories of your system drive recursively for irxcopy.cmd. Depending on how many releases you have processed the list might be very long. Nevertheless, all the files are the same. Simply open one and modify as needed. You will simply have to add your modified file as a new Custom Tool in Release Management. There is no way to overwrite the out of the box tool resources.
How to trigger a rollback based on user input from Release Management 19 January 2015 Donovan-Brown Work (0) Quite often I am asked can a Rollback be triggered in Release Management if a user rejects a step of the release. By default rejecting a step of the release will simply stop the release but will not rollback the system to a previous state. However, you can use the Manual Intervention action to achieve the desired effect. To trigger a rollback based on user input simply add a Manual Intervention action at the bottom of your stage’s Deployment Sequence. If the Recipient rejects this Manual Intervention all the identified Rollback sequences will be executed.
Is DSC an upgrade to Agent-based pipelines? 15 January 2015 Donovan-Brown Work (0) There have been a lot of questions from customers and on internal distribution list lately on Release Management, Agent-based vs vNext and how best to deploy to PaaS. So instead of answering the same questions over and over again I decided to write this post and just point them here. There are a couple of points I want to clarify. First nothing stops you from running a DSC script via the Microsoft Deployment Agent. The agent can run any PowerShell and DSC is just a PowerShell extension and can be executed via the Microsoft Deployment Agent. Second DSC is not an “Agentless” solution. From a Release Management perspective some people describe Desired State Configuration (DSC) as an agentless deployment. That is not a true statement. The LCM or Local Configuration Manager running on the machines is the agent. The nice thing about this is if you are targeting Windows Server 2012 R2 or Windows 8.1 the LCM is already installed and ready to go. But don’t kid yourself: it is an agent. If you are targeting older versions of Windows you have to install Windows Management Framework 4.0 before you can use DSC. Therefore, the experience of setting up an agent based or vNext (I prefer calling these DSC pipelines and will for the rest of this post) based pipeline both require the installation of an “agent” on the target machine. Many users of Release Management see DSC as an “Upgrade” or replacement for the agent based solution. I could not disagree more. There are situations that DSC simply does not do well and others it is great for. If you really look at DSC from the Get, Set, Test perspective it limits its use. A resource that is hard coded to return false from its Test method has no business being a resource. Therefore, running test via DSC makes no sense. As with DSC the same can be said for the agent based solution. There are some things it does great and others where it does not. Many people are running to DSC because it is new and shiny but it is not a panacea. Don’t get me wrong I am a big fan of DSC and can’t be more excited about getting it running on Linux but it is simply a tool in my tool box. I don’t see the DevOps world as a one or the other situation. DevOps is about People, Process and Products and getting them to work and communicate better while automating your pipeline with whatever makes sense for your desired result. If it is DSC, great. If it is PowerShell, Chef, Docker or Puppet, fine. Or maybe it is a combination of all of the above. The goal is a way to easily track, manage and automate the promotion of our code from one environment to another. The agent based solution is alive and well. The goal of deploying to PaaS for example can be achieved today using an Agent based solution that scales much better than the DSC alternative. Let me explain why. In a previous blog post I describe a technique of using a DSC pipeline to deploy to a PaaS website. In that post I simply deploy to a single stage using an IaaS VM as a proxy to execute my DSC. Release Management today does not allow you to have the same server in multiple environments for a DSC pipeline. This means for each stage of my pipeline I would have to stand up a proxy. However, compare this to the Agent based pipeline where the same machine can appear in multiple environments. This allows you to reuse a single proxy machine to target all your stages. I don’t feel DSC is the answer to all our problems. I feel very confident that it is not. We are not in a DSC or bust situation. Solve your problem with the best tools you have which might not necessarily be the newest tool you have.