Enterprise Release Management

Enterprise Release Management (ERM)

ERM enables organizations that desire separate environments/project spaces for application development, testing, training, and production usage of digital solutions. The separation of environments is often desirable for complex applications that are updated often and require rigorous testing.  

Rapid deployment of centrally built apps to multiple local teams

Centralize your app building to a dedicated team of experts, who can then push read-only versions of such apps for multiple teams with the click of a button!

Beyond Applications:

ERM extends beyond applications to include other essential components:

• Data Dictionary

  • ERM maintains a standardized data dictionary.

  • No need to manually create labels and descriptions for case properties; it’s all predefined.

• Lookup Tables

  • Easily manage lookup tables across projects.

  • Consistent reference to data for all teams.

• Automatic Updates

  • Configure automatic update rules within ERM.

  • Keep all instances up-to-date effortlessly.

• Custom Location and User Data

  • ERM handles custom location data and user-specific settings consistently.

In summary, ERM streamlines project management, ensures data integrity, and simplifies deployment across various project spaces. Whether it’s applications, lookup tables, or data dictionaries, ERM ensures everything remains structured and synchronized!

Multiple Project Spaces

Enterprise Release Management (ERM) is a powerful feature that enables structured project rollout within CommCare. It provides a systematic approach for deploying applications and configurations across multiple project spaces. Here’s how it works:

Scenario 1: A centralised HQ team is responsible for building applications for country/project teams that have their own dedicated project spaces on CommCare. No changes are allowed to be made to the applications in the downstream spaces. 

This is an ideal use case for Enterprise Release management for locked applications. A central team of app builders at the HQ level can build as many apps as needed for different projects. These apps can then be pushed downstream to the country/project teams and remain locked for editing. This ensures that no changes are made to the app. This is an ideal solution for similar apps deployed across multiple projects and/or geographies. Since the app structure cannot be changed, all submitted data comes back in a structured format which is then easier to consume. 

Example:

Imagine a real-world scenario where various country offices need to report on similar project indicators. With ERM, you can streamline this process:

1. Upstream Project Space:

   • Create an “upstream” project space where you define the application structure, data dictionary, and other configurations.

   • This upstream space serves as the central repository for your app.

2. Deploying to Country Offices:

   • Push the application from the upstream space to multiple “downstream” project spaces (country offices, for example.)

   • Country offices cannot modify the core structure of the application, ensuring data consistency.

3. Structured Data Collection:

   • As teams in different offices collect data using the same app, ERM ensures uniformity.

   • All fields are captured consistently across teams, facilitating data analysis.

Open

Scenario 2: A slightly decentralised organisation setup where HQ teams build template apps and country/project teams tweak the applications for their own context. 

In this case, the HQ project space is used to build template apps and pushed downstream via ERM. The country teams then unlock the applications for editing by copying it as a new app on their project space. This breaks the linkage between the upstream and downstream apps and all subsequent updates to the app are done by the country team. The process can be repeated every time the HQ team wants to push down new templates for new projects or make wider changes to the older apps pushed downstream earlier. 

In certain cases, ERM can be leveraged for building question libraries or content repositories at the HQ level which can be pushed downstream to be incorporated into the individual apps. In this case, HQ would build and push apps with form content that will be unlinked and copied by country/project teams to their different apps. This is ideal for larger standardised indicators that are common across projects.

Open

Scenario 3: Highly decentralised organisation where country/project teams have complete autonomy over app design and deployment. 

In this case, ERM is used sparingly as each country/project team would be building their own apps with no dependencies on HQ.

Setting up ERM