When I first started with Cireson some months back, we were just wrapping up development on V3 of the self service portal (SSP), and I was tasked with creating the setup program that would make it easy for anybody to install the portal, get version updates, and generally have a good experience in doing so. Obviously, this is an easy task for someone of my developmental caliber ;-). A bit of WPF, some nice animations to keep users occupied while the heavy lifting is done and BAM easy as pie! But then, I was given a much more difficult requirement. A requirement so dreadful that most development managers rarely if ever dare utter the words, let alone put it in an email and send it to the entire team just before morning stand up meeting.
Climactic reveal, and the burgeoning need for DevOps automation
I know you are on the edge of your seat to find out what the words are, so I won’t keep you waiting…”We are going to eat our own dog food” <expletive deleted>. So this changes everything. As a developer, I do like a pretty UI to help me do my work, and install an app now and then, but going into a full blown iterative release cycle, the last thing I want to do is spend my time remoting into a server, loading up an installer, possibly downloading it offline and using sneakernet to get it to the server because it doesn’t have internet access, clicking on a bunch of buttons, and remembering passwords or finding passwords, it can be a real hassle. Whew, what a run-on sentence that was! As luck would have it, there is a better way.
A little back peddling
Now, If you like the setup application, that is great, and I really appreciate it as I did put a lot of work into it, and I think it is quite nice. You get to see IT monkey, and the rolling timer is clever, and you can see Travis usually, and his bright red phone, but I digress. If it works for your environment and you are ok running the click once every few weeks, or every major release, well that’s exactly why we built it, for a typical install it does its job wonderfully. But if you find that the GUI is limiting you, and you want to do more, like customizing SSL as part of the installation, or creating virtual directories off your portal, then please read on.
DevOps automation to the rescue
The remainder of this post will be showing part of how we implemented an automated deployment cycle as part of our ALM (Application Lifecycle Management) strategy. Keep in mind that this didn’t happen overnight, and since we are in an agile world we can be sure that it is not immune to change as iterations progress, and the landscape changes. I won’t go into detail, but our first production deployment to our own servers was more ordeal than it was ideal. Since then we have moved our hardware to Azure, setup a load balancer, integrated our development team into the release cycle, and created a live testing/staging environment (not necessarily in that order) and the latest version that we pushed to our own support portal (I believe we are calling it 3.7 but don’t quote me on that) had our servers showing the famous gone fishing page for a whopping 2 minutes! Having all the pieces in place makes not only the deployment super smooth, but also the quality of the deployment much better.
Diagrams, screenshots, and lists
If you have read to this point, you are probably thinking that I am writing way too much, and need to start posting the code and stuff, so here we go!
First, the infrastructure. Let’s start with a pretty typical/simple layout, portal server running 2012 R2, with SCSM installed locally and a SQL Server. See Figure 1.
In order to upgrade the Cireson Portal Server, we need to do a few things. If we look at the manual process, then it becomes somewhat clearer as to how the automated process should work.
Manual Installation Process
- Download installation media (Click once does this for us, but for this example, we are grabbing the zip)
- Unzip the installation media
- Run the Cireson Setup.application
- Enter the information
- Accept the license terms
- Watch it install
- Make any post installation customizations (virtual dirs., etc.)
The automated process is not much different. I think PowerShell is an ideal tool for the job, but if you want to use something else that’s fine. All examples are in PowerShell. I will include all relevant scripts, so you can follow along, or download them at the end.
In the example script I am expecting a Website called GoneFishing that can be started in place of the portal to give users a nice maintenance screen.
- Download installation media
- The latest version of the support portal setup can be found here https://support.cireson.wpengine.com/portalinstall/Cireson%20Setup.zip
- From PowerShell, you can just execute this command to get that guy: Invoke-WebRequest “https://support.cireson.wpengine.com/portalinstall/Cireson%20Setup.zip” -OutFile “c:\temp\Cireson%20Setup.zip”
- Unzip the installation media
- The PowerShell script for this is a bit longer than one line, so check out the InstallCiresonPortal.ps1 file to see exactly how I do that.
- Prepare the installation files so we can install them with a script
- The GUI installer uses ClickOnce, and so we need to do a little prep work beyond unzipping.
- All the files that the installer needs have the file extension “.deploy”
- We can just rename them to remove “.deploy”
- Again see the InstallCiresonPortal.ps1 script to see how this works
- Execute the InstallPreReq script just to be safe, this will install any prereqs that the portal needs (You may need to restart if this is the first time running.)
- Execute the InstallPortal script
- Add Virtual Directories
- Light up your portal
- Sit back and relax.
A couple things to also look out for:
- Since users browsing your portal will likely have a deep url in their browser, make sure 404 errors on your “GoneFishing” site point to the root url. Doing this once from iis manager is probably the easiest way.
- If the server you are installing the portal on does not have internet access, you will need to manually get/move the zip file and update the script accordingly.
- In the interest of full disclosure, this is not *Really* the script we use locally, although the workflow is the same, and we do use all the parts of the script. Also in the interest of brevity, I just have all the parameters as local variables. In our production implementation the script is split out into more component parts, and executed using TFS Release Manager 2013 to coordinate some of the stuff, but that is another post.
- I have noticed in some of my environments, I run into an issue loading the DacFX with an error prompting to install the DacFX MSI. To fix this, simply browse to the installation folder, and find the MSI folder, run each of those in order (1 – 14) manually to make sure they are all installed. This usually takes care of the issue. Sometimes you may need to restart.
I think that’s about it for now. Please comment if you find any issues with this script, or have a sweet script that you would like to share.