This article provides a general overview of questions and basic guidance around possible K2 patching and update strategies.
To be fully supported by K2 support and eligible for fixes for newly discovered product issues, you must run supported versions of K2 software (i.e. one whose standard support lifecycle have not ended) or have an extended support contract. Refer to the K2 Product Support and Release Strategy page for additional details on support policies.
The final decision on the organization's approach to patching and update strategies are always left to the client's discretion. This article only provides guidelines and recommendations and emphasizes known limitations and restrictions to consider when developing your organization's update strategy. If you have any concerns about K2 updates or patch installations, consider contacting K2 support first.
Update Strategy and recommendations
Before determining your update strategy, you should be familiar with the different shipping vehicles K2 uses to release products and updates. For a summary of the different shipping vehicles, please see the Major and Minor versions, Cumulative Updates, Fix Packs, and Code fixes section in the K2 Product Support and Release Strategy article.
The recommended approach for installing new versions, Cumulative Updates, Fix packs and Code Fixes are as follows:
New ('clean') installations
When you are installing a new, 'clean' K2 environment, K2 recommends that you install the product and subsequent updates as follows:
- Download and install the latest Full Installer for the minor release version that you want to install.
- Download and install the latest Cumulative Update for the minor release version you installed in Step 1.
- Download and install the latest Fix Pack that was released after the Cumulative Update that you installed in Step 2.
- Normally you would not need to install a Code Fix in a new ('clean') installation, unless you already know that you will encounter the issue addressed in the Code Fix in your new environment.
If you have an existing K2 environment, K2 recommends that you install updates as follows:
- Download and install the latest Cumulative Update for the minor release version that is installed in your environment.
- Download and install the latest Fix Pack that was released after the Cumulative Update that you installed in Step 2, but only if one of the fixes in the Fix Pack addresses an issue that you have experienced in your environment.
- Do not install any Code Fixes in your existing environment, unless you have been asked to do so by a K2 Support representative.
Q: How can we determine what version of K2 or K2 update is installed?
A: Please see the article KB001893: How to determine the installed K2 software version, Cumulative Updates, and Fix Packs for instructions to determine what version or update of K2 is installed in an environment.
Q: Where can we see a listing of released versions or cumulative updates?
A: Please see the article KB001421: K2 Product Releases and Build Numbers for listings of the major and minor releases and Cumulative Updates, along with release dates and links to the release notes
Q: Where can we see a listing of available Fix Packs?
A: It depends on your version of K2. The following links may be useful:
Q: How can we receive or view information about available updates for K2 components?
A: Apart from customer communications that are sent out to announce the availability of major and minor versions and cumulative updates, you can also refer to the help.k2.com site for the release notes associated with releases and updates. You can, for example, review HotFix and Update content types for K2 blackpearl KB articles or K2 Five KB articles. You can also subscribe to the RSS feed on the K2 help site. When a new major, minor or cumulative update is released, it will also be added to KB001421: K2 Product Releases and Build Numbers which also contains links to the release notes for that release.
Q: What is the recommended frequency for installing K2 updates?
A: Update management strategy is a client decision, and K2 does not dictate when and how updates should be applied, beyond general recommendations to always run supported major/minor versions as well as making sure that all components in your environment (client/server) run the same major/minor version and on the same update level. K2 may also request that you install a particular update (i.e. code fix, fix pack, or cumulative update) to resolve a specific problem. Your organization's operational requirements, change management policies and procedures, and standard SDLC approach may dictate how frequently you should install K2 updates. Your organization may find a balance between the tested Enterprise IT strategy known as "follow the leader" (i.e. let "new feature keen" firms try new major/minor versions first), and only install new versions some time after release, while applying Cumulative Updates more readily to avoid requesting support when that issue was already fixed in a Fix Pack contained in a Cumulative Update. A sensible approach for applying Cumulative Updates is to review the release notes/list of fixes to determine if a Fix contained in the Cumulative Update is relevant to your environment.
While updating an environment, customers are responsible for testing their solution(s) built on the K2 platform. Always make sure to test the impact of updates on your solutions thoroughly.
Q: If there is an urgent (e.g. security related) update which must be applied as soon as possible, how do we receive such information?
A: There is no K2 security bulletin or urgent mandatory updates which we qualify as security related and push to all clients. But in general you can expect K2 to communicate information about major bugs and breaking changes. With regards to Security, we do not specifically announce all security issues we discover and recommend that being on the latest version is always the best thing to do, as it includes all important security updates.
Q: How do I install Code Fixes?
A: The K2 product support team tracks distribution of Cumulative Updates/Fix Packs and code fixes (the latter are available via support requests only). Support-assisted installation is a requirement for code fixes, to make sure that they are applied correctly. You may log a support ticket for assistance with code fix installation. You can reapply code fixes on your own if you are comfortable with the procedure and if it is necessary, but at the very least the first installation should be done with K2 support participation.
Q: We use multiple environments (e.g. Dev, test and Production). Should we apply an update to the Dev environment first, and after some time apply it for the Production environment? Are there any other tricks?
A: The rules of common sense/ITSM are applicable as with any other software: every update you introduce into your production system has to be tracked, controlled and tested. This must be routed through your organization's own change management process. Every update must be tested in all your environments going from development, to test, to production environment to make sure that issues are solved and working. Also allow some extra time for "regression testing" to see if something else breaks or if new issues crop up.
K2 recommends that your organization keeps track of exactly which updates are installed in which environments, independently of the tracking performed by K2 support.
Also bear in mind the requirement that individual machines sharing a K2 environment (e.g. when you have multiple servers, or workstations with thick-client tools installed), those machines should all be running the same version and update of K2. For example, if your organization uses K2 for Visual Studio to allow developers to deploy to both Dev and Test, when you upgrade your Dev environment, the developer machines should also be updated, and developers cannot deploy to test until Test has been updated as well. You may also want to apply a 'code freeze' approach while environments are being updated, to avoid creating additional variables should something stop working during an upgrade.
Q: What about rolling back an update?
A: Make sure you have a rollback plan for cases where the update installation goes wrong. In the case of a code fix, you should keep backups of any files that were changed. Whenever a database change is applied, you should first make a backup of your K2 database before the update or version is installed. If your organization uses virtualized hardware and you can make machine snapshots, you may wish to update your K2 database and take snapshots of all servers where K2 software is installed, prior to installing an update. Finally, you should plan and follow your organization's planned downtime policies if an update requires your environment to be taken offline for an amount of time.
If you take a backup of the K2 database and then restore that backup at a later point, be aware that there may be temporal discrepancies such as escalations or scheduled workflows firing twice, because of the way those future-dated actions are saved in the K2 database. If you restore an old version of the K2 database, it is possible that escalations or schedules may fire again when you restore the backup database.