we currently have a SuiteCRM environment for development and testing as well as a production environment.
We now want to switch to four systems (Production environment, User Acceptance Test (UAT) environment, Quality Assurance environment, Development environments) in accordance with SugarCRM recommendations (Development Methodology - SugarCRM Support Site).
The developers should implement different requirements (user stories) of the users in the development environments. However, only certain user stories should then be transferred to the other systems.
Here we fear that conflicts in git that are difficult to resolve may arise.
Do any of you have experience in collaborating development of SuiteCRM and can you share your best practices here? How can we avoid problems like merge conflicts?
HI Reinhard
welcome to the forums.
Good to see that a sold, well-engineered framework is being planned there.
When that page recommends 4 environments -that is rather a lot!
Questions to ask yourself:
how long has Suite been in use there - has it been stable, and has the trust of the users?
how do you handle other software projects there - if they use 2, then maybe 2 is enough for your SuiteCRM project too. is there good reason not to copy your normal dev practises (that also reduces cognitive overload for devs, if the processes match across projects).
if you are planning lots of dev on Suite - then setting it up first so every dev can with 1-click spin up their local environment is helpful: and then just have 2 main environments: ‘dev & testing’ and ‘production’.
how many features /changes will be created each week, that will require UAT testing? If not too many, and if the main Dev_Test environment is mostly working every day (ie devs have to ensure proper tests are passed before they can commit to it) - then UAT can happen on that.
which is a long way to ask - how many merge conflicts do you expect? Which is linked to (a) how many devs working in parallel on suite (b) how many teams will have User Stories in parallel (c) will it not be possible to keep each team in a seperate Module or sub-system of Suite?
how much pressure is there from managers to never let a bug through to users? How many users will be on Suite at any one time? Will it be a business requirement to allow rollback at any time?
is the usage in an industry that is highly regulated under law for data protection customer support (eg insurance to consumers)
if it is high pressure to avoid bugs/downtime: could you have backup scripts that run a copy of production; that is read only: so even if there is a big problem, at least users can access information from the past, even if they cannot add new info.
have you a release manager? Will they tool up tools to make release and roll-back in production just 1-click operations?
Maybe you can expand on
However, only certain user stories should then be transferred to the other systems.
which contradicts good agile practise - that all new code should be released to production as soon as possible (so that (a) the users get the benefit (b) if any bugs arise due to unexpected things in production; it can be fixed very quickly because the devs still have in their brains the code they just worked on (2 weeks or months later… and it will no longer be in their brain and take longer to fix) (c) it avoids the wasted cognitive overload of having excess forks in parallel.
Phew - too many questions there, hope it is not too much.