- Best Practices for Managing and Developing Customizations during a Major Upgrade
- Major Upgrade Events & Responsibilities
- Customization Best Practices
- Standard Jive Environments
- Major Upgrade Window Environments
- Related Materials
Best Practices for Managing and Developing Customizations during a Major Upgrade
As you begin to plan a major upgrade for your hosted Jive instance you will need to take several things into consideration to ensure that your upgrade goes smoothly and stays on schedule. All of these best practices and recommendations are covered with you directly via support cases by our account support and hosting teams as you progress through the upgrade process.
If you are not able to follow the best practices and instructions outlined in this guide, then Jive will recommend that you engage Professional Services to aid in your upgrade planning. Failing to follow the best practices defined by Jive will put your upgrade at significant risk and increases the chance that your upgrade will fall behind schedule, increase in cost, and negatively impact the end user experience.
This guide is intended to be used by customers with Jive Hosted instances. Jive Cloud instances are upgraded automatically as new versions are released, and On-Premise environment upgrades are managed by the customers and not Jive.
Upgrade Terminology and Definitions
|Development Environment||Jive environment used for development and debugging that is managed by the customer. There may be multiple developer instances - One for each individual developer or tester.|
|Staging||Jive environment used for testing and acceptance testing that is managed by the customer. The customer uses this for testing and verification before promoting customizations to Pre-Prod or UAT.|
|UAT||Jive environment that is used for user acceptance testing and final functionality verification. This is automatically available for all live Production instances.|
|Production||Live Jive environment that customers and end-users access.|
|Pre-Production (Pre-Prod)||Jive environment that is used for user acceptance testing and final functionality verification during the Major Upgrade Window. During the final Go-Live launch event, the Pre-Production instance becomes the new Production instance. The old Production instance is later decommissioned.|
|Data Refresh||The process of Jive copying the existing Production environment data to a UAT environment. This is only available for live Production environments.|
|Data Copy||The first step in the Major Upgrade. One-time event of copying existing Production environment data to a new Pre-Production environment.|
|Test-Run||The process of Jive copying the existing Production environment data to a Pre-Production environment and updating the environment to the new version. This is only available for Major Upgrades. 2 to 3 Test-Runs are normally scheduled during a major upgrade. Customizations not developed by Jive or Jive Representatives are the responsibility of the Customer or Customer Representative to deploy during the Test-Run and Go-Live.|
The final step in the Major Upgrade. The process of Jive copying the existing Production environment data to the new Production environment and updating the environment to the new version. Customizations not developed by Jive or Jive Representatives are the responsibility of the Customer or Customer Representative to deploy during the Test-Run and Go-Live. Upon successful update and customer verification, traffic is redirected to the new Production instance and the old Production instance is later decommissioned.
|Major Upgrade Window||A period of time when a customer is in the process of upgrading from an older version of Jive to a new major version, e.g. Jive 7.0 to 8.0. A new Pre-Prod instance is used at this time for Test-Run deployments.|
|Environment Manager||Person at Jive who is responsible for managing the schedule, logistics, and resources around your major upgrade project. This person will create new support cases to track the progress of each Test-Run and Go-Live event.|
Major Upgrade Events & Responsibilities
Once a customer requests that they would like to upgrade to a new version of Jive, the Jive team will initiate a series of processes around managing this request. The following diagram illustrates the major steps taken from the time a new upgrade request is received to the final Go-Live upgrade event.
Jive Responsibilities During the Upgrade
Jive will handle the following items during the upgrade process:
- Defining and coordinating the schedule for all upgrade data copies, test-runs, and go-lives
- Creating new Pre-Production and UAT environments for version the customer is upgrading to
- Running an Initial Data Copy from Production to Pre-Production
- Verifying the site is up and available for testing
- Verifying that all official Jive-provided plugins are installed
- Confirming schedule and resources for upgrade Test-Run events
- Confirming schedule and resources for final Go-Live event
Customer Responsibilities During the Upgrade
- Performing all site testing in Pre-Prod
- Reporting to Jive any new issues found during testing on Pre-Prod that are not related to customizations
- Reporting any customization issues to the customization owner
- Upgrading customizations: All custom themes, plugins, add-ons, and WARs need to be compatible with the new version of Jive
- Deploying all custom components to the Pre-Prod site
- Testing and verifying functionality of all custom components in Pre-Prod
- Verifying the success of each Test-Run event
- Verifying the success of the Go-Live
Tips for Having a Successful Launch
- Schedule as soon as possible: Schedule all of your Test-Runs and Go-Live dates well in advance. Jive's upgrade queue may be busy, so we are not always able to do last-minute rescheduling.
- Be responsive in Jive Community: Follow all Test-Run and Go-Live cases in your email inbox in Jive Community so you can stay up to date.
- Continue to check in throughout the upgrade: Check in a week before each scheduled event and confirm that you are still on schedule.
- Know the processes: For each upgrade and test-run, Jive will provide a set of tracking documents and best practices to help you manage the upgrade. Be sure that you thoroughly read these materials so you are not scrambling at the last minute.
- Involve Professional Services: If you have a series of customizations or a complex environment it is strongly recommended that you involve Professional Services in your upgrade planning. Your account manager can help set up this engagement for you.
Please note that if you have purchased a The specified item was not found., many of the scheduling and verification tasks will be performed by Jive's Professional Services team. Jive Professional Services will be your main point of contact for the upgrade, and any questions should be directed to the Jive Project Manager. Additionally, Jive's PS team may also assist with the following services:
- Train you on new features
- Prepare you for the impending change management activities related to your upgrade
- Lay out a technical path that best positions you for success and optimizes go-forward maintenance costs
If you elect to not have Professional Services engaged for your upgrade, then your team will be entirely responsible for ensuring that any customization development is completed and ready prior to the agreed upon Test-Run and Go-Live dates. Jive Hosting is not able to adjust or change the upgrade process. If your organization needs specific exceptions or changes to the process, then you will need to engage Professional Services to work with you directly to meet your needs.
Customization Best Practices
As you move through the upgrade process one key point you will need to take into consideration is how you will develop, manage, test, and deploy any customizations you have. You may need to adjust your existing software development processes in order to successfully deliver your customizations in Jive's hosted environment. Jive has had great success with our established hosting platform and upgrade management processes, so we encourage all customers who develop customizations to follow these best practices in order to stay on schedule and have a successful upgrade.
Jive does not provide support for customizations in the platform during the upgrade process. Customizations may include custom themes, custom plugins, add-ons, or custom WARs. This means that it is the customer's responsibility for deploying, testing, and verifying these components in development and staging environments before performing a Test-Run or a Go-Live. Jive Support will still assist with troubleshooting issues found during the upgrade process, but if Jive Support determines that the issue is caused by a customization, then Jive Support will not be able to provide assistance with resolving the issue. The issue will need to be addressed by the team that manages that customization.
Developing Customizations during an Upgrade Window
There are several key components you need to incorporate into your development process in order to ensure that your customizations do not jeopardize the success of your upgrade:
- Updating customizations: During your upgrade window, your development team is responsible for porting your existing functionality from the old system to the new system and verifying that there is no loss in functionality.
- New feature development: New feature development in your customization should be halted during your upgrade window in order to limit the scope of development work and ensure that your upgrade stays on schedule. The primary focus for the customization provider during the upgrade window is to ensure all functionality available prior to the upgrade is retained in the next version.
- Any new feature development happening during the upgrade window should be happening in a separate code branch that is specific to your previous Jive version. New feature development for an older version of the customization should not impact your upgrade planning.
- These new features can later be merged back into your upgraded customization once you have had a successful Go-Live event. It is critical that you segment out development effort going towards new features and effort going towards upgrading the customizations.
- Testing environments: Jive recommends that you set up a separate development environment and a staging environment in your own hosting environment in order to quickly test and verify all customization functionality. Jive's hosting platform is designed for high availability and performance. Jive UAT, Production, and Pre-Production environments are not meant for iterative testing and debugging, but instead should only be used for final user acceptance testing.
- Testing with production data: Jive recommends that all developers building customizations download a copy of their production database through Jive Cloud Admin and load it in a staging environment in order to do testing against real customer data. This allows for developers to test and debug issues that may not be discovered in a local development environment.
- User Acceptance Testing: Once a customization has been tested and verified in a staging environment, it should be marked as a release candidate. Only these release candidates should be deployed in the Pre-prod environment, where you will need to ensure there is no functionality loss.
- Smoke tests: To aid in the testing process, Jive recommends that the owner of the customization creates a list of manual smoke tests that are ran across both staging and UAT to ensure that there is no functionality loss. These same smoke test should also be done on Production prior to the Go-Live being completed.
Standard Jive Environments
Outside of an upgrade project, each customer will have both a UAT instance and Production instance made available to them. These two instances are available at all times and will be running the same version of the Jive platform.
It is also recommended that customers who are developing custom Jive components also have a development environment and a staging environment set up to aid in the development process. The staging and UAT environments are to be kept as close to one another as possible when it comes to Jive versions, installed plugins, themes, and application configurations. The goal of a staging environment is to have a local environment that your development team has full control over so that they can do rapid testing and debugging.
In order to avoid the need to do live functionality verification against a production instance, a UAT environment is provided for community managers to verify and approve Jive functionality, as well as verify new versions of plugins and customizations. Once a new component is approved it can then be deployed to production.
If a customer would like to have the UAT site updated to match the production environment, then the customer may request a one-time "Production to UAT data refresh" task. This can only be done for live production instances and is not available for Pre-Prod instances. Similarly, if customers want to update their development or staging environments to match their production environment, they can retrieve a copy of the instance's databases through Jive Cloud Admin. How do I access my Jive Database as a Hosted Customer?
Throughout your testing, if an issue is identified, best practices dictate that the issue must be resolved in a development environment first, and then the changes must be promoted and verified against Staging, then UAT, and finally Production. Only production-ready code should be deployed to UAT. If there is an issue with a customization, any troubleshooting or debugging will need to be done on a development or staging environment.
|Owner / Maintainer||Customer||Customer||Jive||Jive|
|Access level||Complete server access||Complete server access|
* Load and stress testing customizations in staging environments may not yield results that match production environments due to differences in system resources. Load testing is prohibited in Jive managed hosted environments.
Major Upgrade Window Environments
During a major upgrade window, a new Pre-Prod instance and new UAT instance are both set up at the same time. All Test-Runs, deployments, and testing are to be done against the Pre-Prod environment.
The UAT environment is not available for access during a major upgrade window. UAT environments are designed to reflect the state of a live Production environment as closely as possible in order to allow for community managers to safely verify functionality without impacting Production data. The UAT environment must be isolated from the Pre-Production instance during the upgrade window in order to ensure that the UAT site can be set up as quickly as possible after the successful Go-Live.
Once the Go-Live has successfully happened, and the Pre-Prod instance has become the new Production instance, then a "Production to UAT" data refresh task will be ran by the Jive hosting team to bring these environments in sync. This will update UAT so it matches the production environment. This data refresh task can only happen for Production instances, and it cannot be done during the major upgrade window.
During the major upgrade window, a large part of the customer's responsibility is updating existing customizations to be compatible with the version you're upgrading to. In order to ensure the success of this effort, Jive recommends that customers create a development environment and staging environment that are managed by the customer. As development progresses, the updated components should be promoted from development, to staging, to Pre-Prod. Only production-ready code should be deployed to Pre-Prod. If there is an issue with a customization, any troubleshooting or debugging will need to be done on a development or staging environment.
This method closely matches the best practices outlined in the "Standard Jive Environment" above, with the exception that you are to treat the Pre-Prod instance during your upgrade as if it were your production's UAT environment. All testing, user acceptance testing, smoke tests, and final verification are to happen in Pre-Prod. Customers are encouraged to continually deploy updated themes, plugins, and add-ons to Pre-Prod in order to resolve identified issues. If an issue is found in a customization on Pre-Prod, then this does not normally warrant an additional Test-Run. These issues are expected to be resolved through an updated deploy to the Pre-Prod instance. If there is an issue that warrants an additional Test-Run then please reach out to the environment manager in your support group to coordinate the next steps.
Test-Runs are meant for verifying that you are ready for a Go-Live launch. Jive recommends that customers treat a Test-Run as if it were your actual Go-Live event. Test-Runs are not to be used to aid in the development or troubleshooting processes.
|Owner / Maintainer||Customer||Customer||Jive|
|Access level||Complete server access||Complete server access|