Over the past few weeks I’ve been diving into automation in general and wanted to share some knowledge. Soon I’ll be writing up an article that dives into versioning and the importance of combining these processes. Anyways…
Tasks that are repeated continually should be easily automated to completion. That’s a pretty hard statement to argue against. Grab a cup of coffee and lets look at some pros and cons of automation, specifically how you build and deploy your products.
Pros:
- Audit trail
- Removal of human error
- Faster
- Part of development process
- No “tribal” knowledge needed
Cons:
- Extra development time
Now Pros are usually easier to come up with and I could continue the list on another five to ten bullets, but if you’ve made it this far you know the benefits of an automated build and release process. One may argue that there is no accountability when automating something but I (and many others) argue back that is the furthest thing from the truth. Having something laid out in source code is the greatest accountability one can reach. So long as the changes are kept track of.
Types of Build Processes
Over the past few months, I’ve been exposed and developed multiple strategies for a build processes. Each one seemed to be written with different set of tools than the last because of that “one” thing that made the process unique. And that is okay! Not every application will be built the exact same way.
Lets take a mainstream product and break down a particular build process. The product has a client front end (mobile or web) and the front end clients talk to a web service that we’ll call the “back end”. What you may not realize at first but all 3 of these “ends” may need different build processes because they are all targeting a different endpoint. Mobile especially will have different endpoint if you’re targeting more than one platform. Therefore, you maybe asking yourself: “Well how can I create a one and all build process?”. You shouldn’t. Really, don’t try and make a overly complicated build process that is resilient to change because in 2, 5, or 10 years when you’re ready to make a change in the way your business works; you’ll be regretting the decision you or another developer made.
Within the past month or so, I’ve managed to create a flexible build process for two mobile apps, five different web services, and five or so command line utilities. These build processes range from simple to complex (thanks to Apple). However, all these build processes were created using PowerShell and no more than 25 lines.
PowerShell for building & automation
We all know PowerShell is great and the answer to most DevOps tasks. In addition, it can be a great tool for building your build and deploy automation because it is so flexible and runs anywhere. No really anywhere, even Linux (now). At first, this journey may seem overwhelmingly difficult to tackle but the key is to take it one step at a time. For example, if you find yourself right-clicking in Visual Studio to publish a web site to a folder on your machine; you could be saving so much time with automation.
Did you know you can use “MSBUILD” to build and execute that same publish steps with the following:
& 'C:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe' "$pathToProject\ProjectFile.csproj" /p:Configuration=Release /p:DeployOnBuild=true /p:PublishProfile=Production /p:VisualStudioVersion=14.0
Really that’s it. Since, publish profiles are part of a solution and project that means any changes to “Production” are caught in your source control management tool. This is where your accountability comes into play! Next add some PowerShell to zip the folder up and drop it anywhere else would be as simple as:
Add-Type -Assembly "system.io.compression.filesystem"
[io.compression.zipfile]::CreateFromDirectory($publishedLocation, $DeployDestination)
See how incredibly flexible that is?! I bet you haven’t even taken a sip of coffee in a while! Not only can you accomplish file copies and zips using PowerShell, but you can create a publish profile that will complete a Web Deploy for you! All you have to do is change the name of the PublishProfile you supply in you’re script (and maybe some credentials).
Distribution
If you or your company is anything like me and mine, the developers don’t put anything into production. Not only does that prevent tribal knowledge for leaking in but it also ensures documentation is correct and accurate. However, distribution can easily be automated using PowerShell or the alike. Once you’re able to do these two things, you’ve officially achieved the ability to have Continuous Integration and Continuous Delivery. Then all you need is something like JENKINS, TeamCity, or any other flavor that comes around and you just need to drop your PowerShell scripts in place and you’ve successfully automated your build and distribution process.
Till next time!