...
- Repositories
- Repositories are logical units in a Version Control System to store Branches of objects that can be assigned permissions for access by different users and groups.
- Branches
- A Branch corresponds to the current status of the job related objects that have been added to the repository by Commit operations.
- Only one Branch at a time should be used for job deployment. Multiple branches are frequently used to organize the contributions of a number of developers who work in parallel on the same sources. It is not a recommended scenario for job development to have multiple engineers work in parallel on the same jobs.
- Branches can be tagged, e.g. assigned a Release number.
- Commits
- Commits include to submit a fully functional and deployable copy of job related objects to a Repository.
- Commits are not intended for backup of working copies for job related objects.
- Releases
- Releases are tagged Branches that are not modified after deployment.
- Release numbers can be applied according to individual conventions. Semantic Versioning is a frequently used standard for release numbering (Major.Minor.Patch).
Use Cases
- Initial creation of a repository with the configuration items of a JobScheduler instance.
- Configuration items are stored in the live folder.
- These items should become part of the repository
- The live folder should be a checked out version of the configuration
- Initial Deployment
- Initially deploy a release to an integration or production environment.
- Update Management
- Deploy a maintenance release to an existing environments.
- Existing job related objects will be replaced.
- Dropped job related objects will be removed.
- Existing configuration items should be considered and maintained.
Rollback to a previous release
- Identify the release to which you want to fall back.
- With Subversion/Git operations get the files of the desired release.
- Deploy the desired release as stated with the "Update Management"
...