Version 1

    This document is intended to serve as a guide for customers and partners who are maintaining their own set of Jive customizations within the confines of Jive's development environment.  It should give the reader some insight as to the components of Jive development environment, as well as the steps taken by Jive PS to release customizations to customers.


    The Pieces

    Every Jive customer project has a JIRA project for issue tracking and a SVN project for source control.



    Jive PS uses JIRA to track tasks and issues for customer projects.  Each custom project lives at, and has its own project ID.  There are a few things that are important to note about the standard customer JIRA project.



    Each line item in a SOW should be represented as a component in JIRA.  Any new feature introduced in a Change Order should be treated the same.  Most issues for a project should have a component assigned, unless it is an overhead task.  At the very least, a new component should be accompanied by an issue of type New Feature that covers the implementation of the feature itself.  More complex features might necessitate several subtasks, of course.  Subsequent issues, such as bugs, improvements, etc., should also point back to a component, for traceability purposes.  This allows us to see all the issues pertaining to a particular component within a project.



    This section will make a lot more sense after reading Jive PS Versioning Guidelines.


    When working on a customer project, there should always be (at least) two active versions: The production release (ex.: 2.1), and a UAT release (ex.: 2.1-d4).  Any issue that involves writing code should always have two Fix Versions specified, a production release, and a UAT release (2.1 and 2.1-d4).  This allows for reporting of issues for a UAT release, as well as for a production release.


    Every version should have a "Perform Versioning Task" issue of type Task.  This issue is mainly for overhead purposes, and covers the creation of SVN tags for a release, as well as the changing of version numbers in the various pom.xml files.  Unlike other issues, this version should only have the current UAT release as its Affects and Fix Versions.



    Jive stores its customer project source code in Subversion, located at, with each customer having their own project within. In accordance with SVN standards, each project will have branches, tags, and trunk directories at the root.  Generally, all new development will take place in trunk.  In the case where there is work being done simultaneously against an older version, and a new version, the new version is done in trunk, while the older version work is done in a branch.  Each version (UAT release) should have a corresponding tag in the tags directory.  As part of the release process described below, when a UAT release is pushed out to a customer, a tag is created for that version (2.1-d4).


    IMPORTANT:  Every commit to SVN must have a valid JIRA issue in the accompanying message.  Be smart about this.  Don't just shove a bunch of changes under a single issue, as that just makes a mess within JIRA, and wrecks the traceability of the project.


    Continuous Integration

    Jive has its own Continuous Integration server that it uses to perform builds and tests against the code committed to SVN.  Unfortunately, this build server is not accessible to customers and partners.  That does not mean an external build system cannot be used to build a customer's custom project.  A CI server, such as TeamCity or Jenkins, could be pointed to the customer SVN project, and pull the code directly from there to facilitate custom builds.  It should be noted that Jive strongly encourages its customers and partners to have some sort of CI solution in place before starting development, as it provides a standardized and consistent environment from which to generate binary artifacts to be deployed to a customer's instance.  It is NEVER ok to deploy something a developer built on their personal workstation.  The results are often polluted and unpredictable. 


    The Release

    This section will cover the basic workflow of releasing a project to a customer.  Note that many of these steps could be automated using a tool like the Maven Release Plugin.



    1. Make sure everyone has checked in their code.
    2. Ensure the CI build was successful.
    3. Make sure the pom.xml files within the project reflect the current version number (2.1-d4).  Any commits to SVN resulting from these changes should reference the Perform Versioning Tasks JIRA issue for this version.
    4. Build in CI.
    5. Copy the development branch (normally trunk) to a tag, named after the current version (2.1-d4), referencing the Performing Versioning Tasks JIRA issue created for that version in the commit comments.
    6. Make sure all issues in the JIRA project assigned to be fixed in this version are resolved.
    7. Release the current version in JIRA.
    8. Create a new UAT release in JIRA (2.1-d5), along with the accompanying Perform Versioning Tasks issue.



    1. No additional functional code changes should have been made since the last push to UAT.
    2. Change the pom.xml files within the project to reflect the production version number (2.1).  Reference the production version's Perform Versioning Tasks JIRA issue in the SVN commit comments.
    3. Build in CI.
    4. Copy the development branch (normally trunk) to a tag, named after the production version (2.1).
    5. Resolve and close the Perform Versioning Tasks JIRA issue.
    6. Release the production version in JIRA.
    7. Optionally create new production and UAT release versions (2.2 and 2.2-d1), along with the accompanying Perform Versioning Tasks issues.