VDI Layering Naming and Change Control
A few of my customers have large teams managing their VDI and all of the desktop layers that make up those desktops. One of them asked for help creating a policy to track changes to those layers, as they had run into trouble with accidentally rolling out desktops using a layer version that was still undergoing testing or not knowing what changes had been made on a specific version of a specific layer. This is a little outside of the normal content that I like to post about on this blog, but we came up with a solid policy that has helped them to get their environment under control, and so I’m going to do my best to explain what we came up with here.
The first important detail to the policy was a strong naming standard. We decided that layer names should be based on two factors, a group specific notation and the name of the application (or set of applications) in the layer. Most applications are not group specific and so do not need a group notation, but occasionally there will be an application (or an instance of an application) that needs to be customized for a specific group of users. In that case, we prefix the application name with that group’s identifier. We chose a prefix rather than a suffix because the desktop administrators were fond of the tile view in Unidesk, which doesn’t display too many characters in the layer names (although the list view, or hovering the mouse over the tile, will show the whole thing).
The next important aspect of the naming convention is the layer versions. Most environments maintain several versions of each application layer, as it allows the support team to roll back in case a problem makes it past the testing cycles. We decided that new versions should be named in the “(testing) <date> #” format. So, a new version created on 9/18/2015 would be named “(testing) 9/18/2015 1”. Subsequent versions from the same day would increment the final number. We decided to include that “(testing)” moniker to make it obvious to every administrator in the environment that that version had not yet passed internal validation testing and so was not to be used on production desktops. Unidesk does not name VMDK files after the version name, so after a version passes testing, we are free to rename the version without introducing any confusion.
The next important detail to the policy was the change logging. We determined that we needed to log what was being changed on each layer for each version, as the customer had run into issues where one administrator made a change to resolve an issue and inadvertently created a new problem that wasn’t detected for some time. By the time the problem showed up, the original administrator was unavailable and so the rest of the team had to reverse engineer his work. We decided to simply create a folder on the team’s file share with a document for each layer. That document has a heading for each version, and high level details about what changes were made for that version. Every time a new version of the layer is created, a new version heading is added to the end of the file… and so the team has a running log of every change that is made to every application in the environment.
The next step is for after the version is created. We decided that we needed an application owner to run application testing, which is obvious, but we determined that we needed to test that layer under 2 distinct conditions. We decided that we needed to test an upgraded desktop as well as a newly deployed desktop. This determination was made after one administrator introduced a change that prevented sysprep from running successfully. That problem was not detected until a new wave of users needed to be added to the system and none of their desktops would provision! After the application validation testing was completed, we finally rename the version to remove the “(testing)” prefix.
When it comes time to roll out the new version, we decided to establish a phased approach. Every desktop team knows about users in their environment who “get it”. These are the more technically savvy individuals who work well with IT and are generally willing to help with testing and give valuable feedback. Since layering technologies give us incredible flexibility and ease of management, we decided that application updates would be rolled out to those users first. After several days of the update successfully running for those users, we would roll the update out to the rest of the user base.
Finally, and this is just as important as the rest of the policy, we need a layer retention/deletion policy. We decided that we would maintain 3 versions of a given application layer in this environment. After the application layer is successfully deployed to the enterprise, the oldest version must be deleted. This step is important, as otherwise datastores can quickly become filled with unnecessary, archived applications.
The first important detail to the policy was a strong naming standard. We decided that layer names should be based on two factors, a group specific notation and the name of the application (or set of applications) in the layer. Most applications are not group specific and so do not need a group notation, but occasionally there will be an application (or an instance of an application) that needs to be customized for a specific group of users. In that case, we prefix the application name with that group’s identifier. We chose a prefix rather than a suffix because the desktop administrators were fond of the tile view in Unidesk, which doesn’t display too many characters in the layer names (although the list view, or hovering the mouse over the tile, will show the whole thing).
The next important aspect of the naming convention is the layer versions. Most environments maintain several versions of each application layer, as it allows the support team to roll back in case a problem makes it past the testing cycles. We decided that new versions should be named in the “(testing) <date> #” format. So, a new version created on 9/18/2015 would be named “(testing) 9/18/2015 1”. Subsequent versions from the same day would increment the final number. We decided to include that “(testing)” moniker to make it obvious to every administrator in the environment that that version had not yet passed internal validation testing and so was not to be used on production desktops. Unidesk does not name VMDK files after the version name, so after a version passes testing, we are free to rename the version without introducing any confusion.
The next important detail to the policy was the change logging. We determined that we needed to log what was being changed on each layer for each version, as the customer had run into issues where one administrator made a change to resolve an issue and inadvertently created a new problem that wasn’t detected for some time. By the time the problem showed up, the original administrator was unavailable and so the rest of the team had to reverse engineer his work. We decided to simply create a folder on the team’s file share with a document for each layer. That document has a heading for each version, and high level details about what changes were made for that version. Every time a new version of the layer is created, a new version heading is added to the end of the file… and so the team has a running log of every change that is made to every application in the environment.
The next step is for after the version is created. We decided that we needed an application owner to run application testing, which is obvious, but we determined that we needed to test that layer under 2 distinct conditions. We decided that we needed to test an upgraded desktop as well as a newly deployed desktop. This determination was made after one administrator introduced a change that prevented sysprep from running successfully. That problem was not detected until a new wave of users needed to be added to the system and none of their desktops would provision! After the application validation testing was completed, we finally rename the version to remove the “(testing)” prefix.
When it comes time to roll out the new version, we decided to establish a phased approach. Every desktop team knows about users in their environment who “get it”. These are the more technically savvy individuals who work well with IT and are generally willing to help with testing and give valuable feedback. Since layering technologies give us incredible flexibility and ease of management, we decided that application updates would be rolled out to those users first. After several days of the update successfully running for those users, we would roll the update out to the rest of the user base.
Finally, and this is just as important as the rest of the policy, we need a layer retention/deletion policy. We decided that we would maintain 3 versions of a given application layer in this environment. After the application layer is successfully deployed to the enterprise, the oldest version must be deleted. This step is important, as otherwise datastores can quickly become filled with unnecessary, archived applications.
Comments
Post a Comment
Sorry guys, I've been getting a lot of spam recently, so I've had to turn on comment moderation. I'll do my best to moderate them swiftly after they're submitted,