added support for legacy tickets

2026-09-28 11:26:27 +01:00
parent 0a689bb11f
commit 83d617a0a7
28 changed files with 2803 additions and 2741 deletions
@@ -0,0 +1,89 @@
+# 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