Understanding content release requirements and process design
Planning your content release process
A number of requirements need to be considered:
- content promotion gates/approvals
- release formalism and separation of roles
- frequency of releases
- quantity of data being hosted (i.e. number of SNOMED CT versions)
- high availability / redundancy requirements and deployment down time
- full release history and ability to roll back to a release point
These decisions will dictate the deployment model being used to get the desired control and appropriate infrastructure
When designing your content release process, a number of factors need to be considered such as
- The need for content gates and approvals
- The level of release formalism and role separation required
- The frequency of content release
- The quantity of data being hosted, particularly the number of SNOMED CT versions
- High availability and redundancy requirements, and whether down time is acceptable for deployments
- The ability to have a record of the full release history and the ability to roll back to any point in that history
These factors will dictate the deployment model and shape the infrastructure and release processes
Scope
Content release processes for developing and releasing content includes
Where users are only using content published by others, these considerations may not be relevant.
Development and review
The development and review process can be performed using the Snapper:Author tool.
Content can also be added to Ontoserver using the FHIR mechanism of packaging resources in a bundle.
Scaled instances
Ontoserver can operate in a cluster mode, with multiple instances of Ontoserver (containers) serving a single endpoint. This is achieved using a load balancer in front of the Ontoserver instances to route these requests. For details on this approach, refer to Horizontally scaled read-only endpoint.
The section Horizontally scaled read-only endpoint discusses a number of choices and ramifications relevant to release process which should be read prior to reading the procedures in this section if a scaled read-only instance is being used.
Zero downtime deployments
The procedures in this section are described in terms of a non-zero downtime deployment model for simplicity. However zero downtime deployments are possible and are described in Zero down time deployments and the procedure principles remain the same and their details can be adapted around a zero downtime deployment process.
Approval
The first step in release is approving new/modified content for publication once the authoring process is complete. Depending on your deployment model, different approaches are require.
Publication
Release processes for publication can vary.
Rollback
Rollback is possible with some deployment models.
Rollback of release state under this deployment model is not trivial. The Authoring server’s syndication feed state must be manipulated into the desired state and the publication process followed again to correct any content publication issue requiring a rollback.
Rollback is achieved in this model by redeploying to the Production server using the preload feed/s on the syndication server that represented the last known good state. The syndication server can store many feeds over time representing these release candidate states, and the Staging and Production read-only servers can be rolled forward/backwards to these stable release points.