VCS best practice for development vs production

Mike Matthews - Omnis omnis at lineal.co.uk
Fri Jan 26 11:49:03 UTC 2024


Hello Paul,

We struggle with this same problem as well.  We have a multi library setup.

Mike Matthews

Lineal Software Solutions
Commercial House, The Strand<x-apple-data-detectors://1/1> Barnstaple, Devon, EX31 1EU<x-apple-data-detectors://1/1>

omnis at lineal.co.uk<mailto:mike.matthews at lineal.co.uk>

www.lineal.co.uk<http://www.lineal.co.uk/>

www.sqlworks.co.uk<http://www.sqlworks.co/>



On 26 Jan 2024, at 09:40, Paul Mulroney <pmulroney at logicaldevelopments.com.au<mailto:pmulroney at logicaldevelopments.com.au>> wrote:

Caution: This is a message which has originated from outside the organisation. Ensure the sender is trusted and the content is safe before opening links or attachments.



Hi Everyone,

Our biggest client has given us some major projects to be done, while at the same time they want to keep sending us maintenance items to fix.  In times past we've been able to arrange it so that the big changes are relatively separate from the production code, so we don't have to worry about introducing bugs into production.  However, it's coming to the place where that is no longer feasible and we are looking at a way to setup two branches - Production and Development.

The Production "branch" (for want of a better term) is the live system, and maintenance patches are done here.  The Development branch is where we're building the new major work that may be a significant change from the old system.

We're thinking about two approaches:
1. Using two Omnis VCS repositories - Production and Development.  I can see problems with this approach - for example, maintenance changes need to be done in both VCS (double entering code ... not good); when the Development version is ready to deploy, how do we get it into Production, etc.
2. Somehow using the JSON conversion tools and git to merge the Development into production.  The process would be something like: Omnis -> JSON -> git merge -> Omnis.  Lots of manual process, and we'd need to be smart about dealing with merge conflicts.

I'm sure that other Omnis developers grapple with this issue - what's considered best practice for Omnis source code control when you're working in two environments?

I would appreciate any insights that people might have with this!

Regards,
Paul.






"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."  Brian W. Kernighan
--
Paul W. Mulroney                                            We Don't Do Simple Pty Ltd
pmulroney at logicaldevelopments.com.au<mailto:pmulroney at logicaldevelopments.com.au>       Trading as Logical Developments
https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.logicaldevelopments.com.au&c=E,1,7H5kR3n1PZbPe3VM2foaiLrNiZutUBJ1IvHQKdE1VzrYDXFQ_b4XH1xnjlEeRcVcEqx_0bk6RaULrmjpk5iX1olS3QHwGg7ndKaNE7nAojxe1OzHyLQJ&typo=1                   ACN 161 009 374
Ph: +61 8 9458 3889                                       86 Coolgardie Street
                                                                        BENTLEY  WA  6102



_____________________________________________________________
Manage your list subscriptions at https://linkprotect.cudasvc.com/url?a=https%3a%2f%2flists.omnis-dev.com&c=E,1,zKj4xAqW7rOpMc_iZXs6BroMZ6L-U3sXKPNCoc2_Sm8egSd562ejHrF5eZdHixKn_OnXh9Leq0XPiUwOa2OoV0XbRYA6_ftA389n5_1BY6kshZHsyDDcQg,,&typo=1
Start a new message -> mailto:omnisdev-en at lists.omnis-dev.com



More information about the omnisdev-en mailing list