Introduction to Release Management

Server Environments

Release management in software development involves deploying a project through multiple environments. Each environment serves a specific purpose in the release process:

• Development: Developers implement new features and changes in this local environment.
• Test: Use this environment to deploy and test features that are under development.
• Acceptance: Deploy releases here to validate completed features before moving to production.
• Production: This environment hosts the release that has passed all acceptance tests and is available to end users.

Typically, the production environment runs an earlier version than development, and often lags behind test and acceptance environments as well.

Diagram: The diagram displays four deployment environments in sequence: Development, Test, Acceptance, and Production. Each environment is represented as a colored rounded rectangle. Arrows indicate the flow from Development to Test, Test to Acceptance, and Acceptance to Production. Development contains 'MyProject version 1.1', while Test, Acceptance, and Production each contain 'MyProject version 1.0'. This shows that development is ahead of the other environments, which are running an earlier version.

Repository Data

A typical software project includes three main components:

• Code
• Configuration
• Content

In Bloomreach Content projects, code is managed as a Maven project and stored in a version control system such as SVN or Git.

Both configuration and content are stored in the content repository and are collectively referred to as repository data. Configuration includes elements such as users, groups, document templates, website templates, and CMS UI component wiring. Content includes documents and images.

Definitions used in this documentation:

• Repository data: All data stored in the Hippo Repository, including both configuration and content.
• Configuration: Repository data managed by developers and administrators to control system behavior.
• Content: Repository data managed by CMS users to maintain websites.

Repository data is organized as a JCR node tree. Key repository paths include:

• /content: Stores all content, including documents, images, and assets.
• /hippo:configuration: Contains all CMS configuration, such as plugin configurations.
• /hippo:namespaces: Stores document namespaces, which define document types and editing templates.
• /hst:hst: Contains configuration for all publication channels, such as websites and mobile sites.
• /hst:hst/hst:configurations/[channel_name]/hst:workspace: Stores user-created content such as pages, site menus, and components.

Release Management and Repository Data

Release management for code is typically handled by creating tags in the version control system and generating Maven artifacts (such as JAR or WAR files). This process is standardized and automated, allowing straightforward deployment to any environment.

Managing releases for repository data (configuration and content) is more complex. Unlike code, repository data is likely to change in production after deployment. End users regularly create, modify, or remove content, and administrators may update configuration. When deploying a new release, you must address the following:

• Merge configuration changes with existing configuration.
• Apply changes in content structure to existing content.

A new release must update the existing repository data while maintaining data integrity. This often requires modifying existing data within the repository.

Ideally, a software release should be self-contained and include everything needed to update repository data automatically. In some cases, you may need to perform a repeatable set of manual steps. This approach ensures consistent and reliable verification of each release throughout the release management process.

Summary

• Bloomreach Content projects store both content and configuration as repository data.
• Repository data changes over time in production environments.
• Each new release may introduce changes to configuration and content structure.
• When deploying a new release to production, you must update existing repository data to align with the new release standards.