K2 patching and update considerations
kbt129871
PRODUCTK2 blackpearl
K2 smartforms
BASED ONK2 blackpearl (all)
SEE ALSOFix Pack
Code Fix
This article was created in response to a support issue logged with K2. The content may include typographical errors and may be revised at any time without notice. This article is not considered official documentation for K2 software and is provided "as is" with no warranties.
LEGACY/ARCHIVED CONTENT
This article has been archived, and/or refers to legacy products, components or features. The content in this article is offered "as is" and will no longer be updated. Archived content is provided for reference purposes only. This content does not infer that the product, component or feature is supported, or that the product, component or feature will continue to function as described herein.
Objective
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.
Final decision on the exact approach to patching and update strategies are always left to the client's discretion and this KB only provides guidelines and recommendations; and emphasizes possible limitations and restrictions which must be considered.
Before You Begin
If you have any concerns about K2 updates or patch installations, consider contacting K2 support first.
How-to Steps
Before addressing these questions, it is necessary to distinguish between major and minor version updates as opposed to CU, FP and cold fixes. You can find some information about this here: K2 Product Support and Release Strategy.
Below are definitions of different types of releases and updates:
• Major release (e.g. K2.net 2003, K2 blackpearl) represents a major product generation of the K2 workflow/BPM product set. Available via the customer portal.
• Minor release (e.g., K2 blackpearl 4.7) – minor releases are released on 12-month cycles and represent a minor product update that includes the latest updates and new functionality. If we compare this with Microsoft products it is something close to SP or R2 releases. An even better analogy is new updates/builds of Windows 10 (Anniversary update, Creators update) which include a lot of fixes and new features but are still the same Windows 10 OS. Available via the customer portal.
• CU/FP (Cumulative Update/Fix Pack) – these are publicly available updates for current minor releases. Closest analogy is SharePoint CU.
• Codefixes – these are patches or fixes which are not publicly available/widely distributed and made available for specific clients with very specific issues to address them when no other solutions/workarounds are available.
The questions below are mainly about CU/FP and codefixes, if not noted otherwise. The answer may be different depending on what type of “patch” we're referring to, but the main distinction here is the release update and CU/FP/codefix.
Q: How can we view information about available patches for K2 components?
A: I may not be aware of all client facing communication channels we do have, but what you can definitely use is the K2 help site: K2 blackpearl KB articles
From the URL above, you can filter out the K2 KBs by HOTFIX and UPDATE category. You can also subscribe to the RSS feed on the K2 help site.
Starting from 4.7, release cumulative updates (CU) for K2 blackpearl are being released on a bi-monthly basis. As soon as a CU is published information about it is added on the K2 Product Releases and Build Numbers page. Next to each CU you can find a link to its release notes page, which in turn contains links to fix packs (FP) released for this specific CU.
Cumulative Updates for K2 4.7 are released approximately every two months during the product support cycle. They are available for download from K2 portal immediately after release.
Fix Packs for K2 4.7 CUs are released every week, they can be obtained upon request from K2 support.
Cumulative update means that you only need to apply the latest version, any given versions contains fixes from all previously released CUs and FPs.
FPs listed for each CU on respective release notes include cumulative (meaning latest FP contains fixes from all preceding FPs), but to get a FP you need to log a support ticket and install it separately.
We keep releasing Fix Packs for these CUs and make new fixes available for 4.7 clients. Before 4.7 was released, CU type updates were not publicly announced and we may expect more improvements in the way CUs and FixPacks are distributed, but for now you have to request them via K2 support.
Q: What is the recommended strategy for K2 patching: should we install the patches as soon as they are available? Or is there a scheduled plan to do it (e.g. twice per year)?
If we speak about CU/FPs and not major/minor releases, then K2 software is no different than any other software product. Patches made available for clients mainly to introduce new features and solve problems - so patch management strategy is a client decision, and K2 does not dictate when and how patches 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 patch level.
We do support major/minor versions in accordance to our support policies and again decisions about such type of upgrades is on the client side. It is necessary to understand that this type of upgrade may be easy or more difficult depending on the specific environment (its complexity) and internal expertise.
While doing upgrades the CUSTOMER is responsible for testing solution(s) built on the K2 platform. Always make sure to test update impacts on your solutions thoroughly.
In terms of update frequency it may be recommended to strike a healthy balance between well tried enterprise IT strategy known as "follow the leader" (i.e. let "new feature keen" firms try updates first) and apply updates with significant delays after release while applying CUs more readily to avoid requesting support answers when it was already fixed in a patch/CU. A sensible approach for the latter is reviewing CUs release notes/list of fixes and see if something is relevant to your deployment and then applying them. If you're not going to move to the next version periodically make sure to apply some well tested CUs in case there was no need to apply some of them shortly after release.
Q: If there is an urgent (e.g. security related) patch, which should be applied ASAP, how do we receive such information?
A: There is no K2 security bulletin or urgent mandatory patches 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 to apply a patch? Can we ask someone from K2 to perform the patch remotely?
A: K2 support is ready to assist with installation of patches in your environment. K2 support tracks distribution of CUs/FPs and codefixes (they are available via support requests only) and we normally insist on support assisted installation (this is a requirement for codefixes).
Support assisted installation of codefixes is intended to make sure that they are applied correctly - when an installation is done wrong it may break things and/or generate new support tickets. You are always welcome to request assistance with codefix installation. You can reapply patches on your own if you are comfortable with that and if it is necessary, but at the very least the first installation should normally be done with K2 support participation.
Q: Should we apply a patch for the DEV/UAT platform first and after some time apply it for the prod platform? Are there any other tricks?
A: The rules of common sense/ITSM are applicable as with any other software: with every patch or update you introduce into your production system has to be tracked, controlled and tested. This always has to be routed through your own change management process.
It is recommended for the clients to track patches and updates installed in their K2 environments. Maintaining records about which patches were received from K2 (irrespective of tracking performed by K2 support).
Every patch and update have to be tested in all your environments going from development, to test, to UAT and eventually to the 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.
Make sure you have a rollback plan for cases where the update installation goes wrong.
The above-mentioned process should be considered as common sense and normal practice no matter how high/low patch quality is. You just do it to be on the safe side with any software so that problems/issues are isolated before they have any negative impact on your business.
