I’ve been working with Citrix products for 13 years and a part of Citrix Consulting for almost 5 years. In that time, I’ve realized that the technical challenges have changed from time to time, but the organizational and administrative challenges remain unchanged.
Topics like infrastructure layout, application delivery methods, project, change and release management are often not defined all that well. These circumstances lead to issues like quality constraints and human resources bottlenecks, which have impacts that are often bigger than the technical problems.
As such, I decided to write a blog series about the importance of business processes as they relate to Citrix virtualization products. Given that such processes are specific to every company, please don’t expect to receive a full set of definitions that you can copy and paste into your environment. The intention of this series is to give you a direction and an idea of what such processes might look like.
The first topic I would like to address is the release management. Even though most companies do have release management defined, I still consider this as one of the biggest pain points Citrix teams are struggling with. And the main reasons are the bad or wrong definition of processes and the fact that nobody really follows them. There is only one thing that is worse than these points: having no release management defined at all!
No release management means having no framework, no rules and no regulations for your users and stakeholders (e.g. application owner). Thus, the stakeholders might define their own release management and you have to follow their processes and not vice versa. Stakeholders want to implement changes with high quality, no costs and as quickly as possible. This leads again to resource bottlenecks because of unforeseen and/or high numbers of uncoordinated changes. And guess who has to handle this problem? Right. The Citrix team in your company.
Before starting with the deep dive of Citrix related release management, I would like to highlight the two most important facts about this topic:
- Be aware that the definition of release management or any other department overlapping processes needs to be an internal IT strategy and driven by the management. A process defined by the Citrix team only will not be recognized. All members have to be involved, to successfully standardize the processes across all departments. Everyone needs to speak the same language.
Although standardization across all departments is necessary, it is also important to consider the individual needs of all departments and to permit minor adaptions of the processes to those needs. A one-size-fits-all process is possible, but it might not be the most efficient thing for all participants.
- Involve your internal application owner, business partners and users as much as possible. Engage with them on a new concept for your release management and show them directly the current situation and problems. We all know that no one likes changes, especially if they influence costs, release cycles and processing times.
Change is hardest for companies with a weak or non-existing release management, because stakeholders will complain that the new process presents some challenges for them. The truth is that the implementation of a good release management process will have an impact on the daily business for everyone and sometimes they come with “growing pains.” The definition of such processes helps the Citrix team to get more time and resources to handle and coordinate changes. Furthermore, it also increases the quality of the solution and deliverable and this needs to be highlighted. At this point, you have to be a salesman and demonstrate the benefits for all parties.
Define a proper release cycle
Now let’s talk about the release cycle. Usually, a Citrix environment consists of three areas:
1) The application back end systems
2) The front end (server/desktop VDAs) with the appropriate applications installed
3) The Citrix infrastructure (Delivery Controller, Provisioning Services, StoreFront) including the respective backend systems (SQL)
Whenever I do work related to business processes, I divide those areas – back end, front end and Citrix infrastructure – to be able to look at these topics separately and to create a common solution.
In relation to the release cycle, the characteristics of these three areas are summarized as follows:
- Backend: Exclude the changes that directly influence the front end; all releases for the application back end can be planned independently of the Citrix team.
- Frontend: Even though the so-called server or desktop OS VDAs are in the hands of the Citrix administrators, most changes to the front end need to be done on the request of an application owner rather than the Citrix team. Further, it’s not unusual for an application frontend change to be performed in tandem with a back end change. Last but not least, almost every change on the front end has an impact on back end usage. Therefore, a release cycle of server and desktop OS VDAs needs to be aligned with other departments, as well.
- Citrix Infrastructure: The infrastructure release cycle is mostly driven by the Citrix department itself. Components like StoreFront, Provisioning Services, Delivery Controller and License Server are in the responsibility of the Citrix team and changes mostly do not have direct dependencies to the application frontend (XenApp/XenDesktop 7.x-based Server/Desktop OS VDAs) or backend. Hence, the planning of the release cycle of the Citrix infrastructure can be done independently of other departments. Nevertheless, sharing information about the content of the changes to other teams is important, because every change can have some unforeseen dependencies and conflicts. This also applies to changes at the frontend and backend side.
After reading the summary of the characteristics, you might have already realized that the challenging part is the frontend release cycle. Changes are mostly driven by application owners, but the effort is on the Citrix team side. In addition, you don’t have only one application installed and you are not only dealing with one single application owner. Therefore, it’s sometimes quite hard for the Citrix team to implement the changes, while coordinating all organizational stuff as well. And this can be solved through well-defined release management.
Now, please take a seat, because the next statement will shock you or give you at least a good laugh :-).
Due to the fact that every change is time-consuming and relative to the number of available Citrix resources within the companies in relation to the amount of work, I recommend four (4) releases per year for Citrix infrastructure and application components.
By now, I hope you have overcome the state of shock or finished laughing. Let me explain why I think, four changes should be sufficient.
First of all, we can ignore the number of changes on the backend line, unless the modification has an impact on the Server/Desktop OS VDAs too.
The Citrix team is responsible for Infrastructure releases. You should be able to define your own release cycle and I don’t see any reason to perform more than four releases per year, when Citrix itself doesn’t provide more than four releases during the year for most of its components. If you are not driven by features, I highly recommend to consider the usage of LTSR based versions. This way, you will further reduce the amount of infrastructure changes, while using the most stable version.
To be fair, I haven’t added the installation of security hotfixes to my plan, because dealing with this topic is a question of philosophy. Almost every customer has a different opinion on how frequently security hotfixes have to be installed. Nevertheless, I think it should be possible to add your hotfix installation schedule to almost every release cycle plan. However, do not forget to perform proper testing for hotfixes as well.
Now, you may say, four releases for application changes sounds very ambitious and in some cases very hard to realize. I fully agree with you. But I think it should be possible for at least 50–70 % of your application portfolio to fit into this release cycle model. When I talk about application changes, I mean modifications in conjunction with an image update (let’s call them major changes). There are several system and application-based changes, which might be realized through GPO updates. Furthermore, App-V Shared Content Store or redirection of applications to a file share will reduce the dependency to the image management, as well.
Such changes can be categorized as minor, because the effort is much smaller than for major changes. The key to success for the major changes is a proper planning. As already mentioned, if the release management process is defined together with all stakeholders, you will have a good chance to get to four releases per year. Believe me, I’ve seen companies with this strategy and it works like a charm.
It’s important that everyone is involved in advance regarding the upcoming yearly release cycle plan, to be able to create a proper planning for the appropriate applications. In my plan above, I’ve scheduled one release for every quarter for all components. I’ve shifted the releases from the quarter end business time, because this time of period is critical to all companies and should not be disturbed by application changes. In addition to that, I’ve also defined a change freeze time frame, where no changes can be implemented due to a business critical period. The dates of a change freeze should be chosen based on the industry’s busiest time period.
You can also split the release dates of infrastructure and application based releases, to reduce the amount of changes and the failure potential. In this regard, I’ve seen both approaches and both have its own pros and cons.
You might have already observed that I do have added additional non-quarter-release changes to my plan too. The fact is, that you can’t restrict all applications to four releases per year. This is simply impossible. For example, there are applications that are driven by government regulations and need to be updated on a monthly frequency. Additionally, you will always have the one application owner, who has a high critical change that needs to be implemented yesterday. That’s just how our IT world works and has to be accepted at one point. But at the end, this additional effort needs to be paid by someone, otherwise everyone will request such changes every now and then.
You will see, as soon as costs are part of the game, suddenly everyone will be able to follow your plan :-). Nevertheless, implementing multiple changes at the same time during non-quarter-releases should be avoided, due to resource constraints.
Introduce Service catalogs
Covering the requirement regarding additional individual changes and to address costs properly, leads me to my next chapter, the service catalog. I hope all of you agree with me, that all additional unplanned effort needs to be charged to the requestor of the change. This happens in “real life” as well. If you are building a house and request further changes in the bathroom, you will have to pay for every single bit. This sounds logical to me. So why shouldn’t this be a valid approach for the release management of Citrix components (or any other one)?
To be able to identify additional efforts and to offer your stakeholders or users a proper individual release and change management framework, you should introduce an IT wide consistent service catalog. This way every customer can get its individual service, while ensuring that the Citrix team (or any other department) knows exactly what kind of service, quality and scope is expected. The following example is just a brief high-level overview, to give you an example of what I mean:
In contrast to my plan, I hope your service catalog is several pages long and defines every single piece of your offered service. Do not only define what is included but also what is excluded.
Using different kind of categories will allow the users and application owner to choose a model according to their needs. A better/higher category allows the stakeholders to be flexible and perform changes more frequently, but also has a direct impact on the costs of the service. From my point of view, this is a fair solution for all participants.
At the end, all of the process definitions mentioned above will be useless if they are not documented properly. Therefore, please use centralized tools to be able to describe the process and track your releases.
I hope you had fun reading, even though it’s a very dry subject. Please share your thoughts in the comment field.
Thanks & best regards
Architect | Consulting Services | Central & Eastern Europe