Customization Best Practices
As you begin to plan your customization project you will need define a set of best practices for how your custom code will be introduced to your various Jive environments. Customizations may include custom themes, custom plugins, add-ons, or custom WARs. These project plans need to consider how you develop, manage, test, and deploy your customizations in your Jive environments. Building your custom code is only the first step.
You may need to adjust your existing software development processes and schedules in order to successfully deliver your customizations in Jive's hosted environment. Jive has had great success with our established hosting platform and allowing customers to customize their communities, so we encourage all customers who develop customizations to follow these best practices in order to stay on schedule and deliver a seamless customer experience.
There are a variety of customizations you can develop and deploy to your Jive hosted community:
- Custom Theme
- Custom Plugin
- May include Apps, Tiles, External Storage Frameworks, Jive Anywhere Cartridges
- Custom WAR
- And more...
Important Developer Resources
- Jive Developers | API Documentation, Developer Community is the best starting place for learning more about Jive's customization capabilities
- The Jive Platform - Developer Resources has a list of different customization options and various tutorials and technical documents to help aid your development team
- The Developer space is the go to resource for asking the Jive Community developer related questions and to find helpful developer related documents and blog posts
Standard Jive Environments for Testing and Deploying
All Hosted Jive customers 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. The UAT environment is provided enable you to verify your configuration settings and customizations without having to touch your production environment.
Your provided UAT environment cannot be used to test new unverified code or aid in rapid development cycles. It is 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 to enable 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 (On Premise)||Customer (On Premise)||Jive (Hosted by Jive)||Jive (Hosted by 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.
Severity 1 Issues
A severity 1 issue is defined as a issue that has significant to critical business impact on a production system, resulting in a customer's production system being either down, or functioning at a significantly reduced capacity when taken as a whole.
During a severity 1 issue it is the Jive Support agent's primary responsibility to get your community back to a functioning state for all users as soon as possible. If the support agent determines that your customization may be causing the severity 1 issue, then agent will work directly with you to either remove the customization in order to restore the site or will outline the next steps for your team to deploy an updated customization that will fix the issue. Jive will not assist in fixing your customization. It is not Jive's responsibility to troubleshoot, fix, or update customizations, even in severity 1 scenarios. It is the responsibility of the owner of the customization to fix the issue.
Learn more about severity 1 issues here: Best Practices for Creating a Severity 1 (sev1) Case with Jive Support
Jive Cloud Admin Access
Jive Cloud Admin (JCA) is a tool community managers and administrators can use to manage their Jive instances that are hosted by Jive Software. The tool can be used to do system restarts, system deploys, updates, and manage maintenance windows. For managing customizations, JCA is the tool you will use to deploy any custom code, like themes, plugins, or WARs, to your Production or UAT environments.
Learn more about the functionality of Jive Cloud Admin here: Cloud Admin for Jive Custom
Jive Version Upgrades
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.