Welcome to Sentinel Docs

Sentinel EPRO

This document details the Sentinel development process that will prevent collisions and code overwrites it's a living document and will be updated frequently and as the process is refined.

The MPBA Helpdesk is available at Helpdesk.

This documentation used mark down files, if you wish to read more please checkout out Mark Down Guild.

One important aspect of this is that in an ideal world one would develop on a local system with a suitable ODBC driver, if this is not available then we have made a development environment for each developer This system resides on the MPBA AS400 server, the details of this developer system is detailed below.

This may be in some cases informing developers of how 'git' does its work its not a definitive guide to git and anyone who is unsure should reach out so that any issues can be quickly dealt with.

On important aspect of this system is to use a proper git branch structure no longer should developers be working on the master branch, the master branch is reserved for production servers only. Developers should always create a branch off develop which will contain the latest developer codebase.

Git is a DVCS we are all used to the older file based SCM's like subversion and PVCS a DVCS only records the changes. its important to understand that in every case its better to go git pull and push frequently.

Also do a git fetch this will download new branches for you

Please do git pull and git push as frequently as possible.

Also another useful command is git status the output form this speaks for itself as does git log.

Commit Messages

Please make you commit messages useful for developers reason being we can search for a commit message and isolate changed code quickly so "Module Debug" is not helpful but "Module debug - corrected issie with service provider and updated .gitignore" is far more useful

Production Branches

Production servers will only ever use master or main these are considered to be protected branches there will not be used to make live edits under any circumstances. the only exception is a Priority One emergency with a system down and in operable, even in this case the developer must ensure that develop is also upto date.

In the case of such an emergency the assigned developer should create a new branch hotfix/issue-name and perform the fix task in there and merge back into master and then master though to develop.

git branch hotfix\error-500-sparos

then

git checkout hotfix\error-500-sparos

perform your fixes and verify they are ok push all changes to gitlab and

git checkout master

then

git merge hotfix\error-500-sparos then

git push origin master

then verify fix worked ok finally

git checkout develop then

git merge master &&& git push origin develop

All of your fixes are in place and merged back.

Branch Model

The following branches are permitted

  • 'master' or 'main' for production servers only
  • 'develop' main branch for development environments
  • 'qat' for UAT servers
  • 'stage' pre production servers *** if used
  • 'issues' for code fixes
  • 'feature' for major improvements and new systems
  • 'hotfix' for emergency fixes
  • 'archive' this is for copies of various branches for convenience
  • 'release' for candidate releases that are production ready and may be used on a pre-prod server