90 lines
3.5 KiB
Markdown
Executable File
90 lines
3.5 KiB
Markdown
Executable File
# 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](https://helpdesk.mpba.dev).
|
|
|
|
This documentation used mark down files, if you wish to read more please checkout
|
|
out [Mark Down Guild](https://www.markdownguide.org/).
|
|
|
|
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
|