Release Management Concepts
Environment in which customers and end-users verify a release against functional requirements and consequently accept or reject it.
Mechanism used to create, update or delete configuration or content at application startup.
Medium for delivery of content. Typically a web or mobile site. Managed in the CMS application and synthesized and rendered by the delivery tier.
Period of time during which users are not allowed to make any changes to channels in an environment. Typically goes together with a content freeze.
Web application used to create, store and maintain content and channels. Packaged seperately from the site application.
Web application for developers and system administrators providing access to low level content repository structure and date. Sometimes used to make manual configuration changes or to export or import configuration.
Program code for an application. Typically fully contained in a release and transparent to all stakeholders other than developers.
Application settings for a particular environment. A release can introduce new configuration or require updating of existing configuration.
Data such as documents or images that is created and maintained by users in the CMS application and rendered on web pages by the delivery tier.
Defines data structures of the content managed in the application. A release can introduce changes to the content model and require updating of existing content.
Period of time during which users are not allowed to make any changes to the content in an environment. Typically goes together with a channel freeze.
Delivers content managed in the CMS application as web pages in a channel. Packaged in the site application, seperately from the CMS application.
The acronym DTAP is short for Development, Testing, Acceptance and Production and expresses a phased approach to software testing and deployment. In some organizations it is referred to as staging.
All the activities required to make a release available for use in an environment.
Environment in which developers develop and possibly test a software application. Hippo developers typically manage their own personal development environment on their computer.
Collection of network servers running a software application that is being developed, tested or used, and any required supporting systems (e.g. database server).
Java-based programming language used to write scripts.
Process to determine if a deployment has been successful, typically by performing a smoke test.
Environment in which end-users use a release on a day-to-day basis.
The finished software product of one or more development life cycles that can be deployed, run and used. Referenced by a release version number.
Operation returning an environment back into a previous state, typically the state right before a (failed) deployment.
Web application containing the delivery tier.
Automates changes to be made to content and/or configuration. Commonly implemented in Groovy and used to perform updates and upgrades.
Preliminary test to reveal simple failures severe enough to reject a release.
A phased approach to software testing and deployment, also known as DTAP (see above).
A person, group or organization with an interest in the software application's release management process.
Environment in which developer, testers, project managers and product managers test a software application under development. Test environments are typically managed informally by the development team and periodically reset.
Changes in content or configuration required by a content model change or configuration model change introduced by a release.
Changes in content of configuration required by a content model change or configuration model change introduced by a new version of Hippo CMS or a new version of a plugin.