VCS best practice for development vs production

malkishtini at malkishtini at
Fri Jan 26 15:11:17 UTC 2024

We have submitted an enhancement request to Omnis support for the VCS API enhancement.(which Alan had requested below) - ST/VC/820.
This enhancement will help a lot in building a deployment process.


-----Original Message-----
From: omnisdev-en <omnisdev-en-bounces at> On Behalf Of Alan Davey
Sent: Friday, January 26, 2024 9:21 AM
To: OmnisDev List - English <omnisdev-en at>
Subject: Re: VCS best practice for development vs production

Hi Paul,

In addition to what Mayada mentioned, we are also using Alex's omniscli tool.  This allows us to script the process that transfers classes between our VCS repositories and do daily builds from each repository with the Omnis VCS API.

Currently the API can only checkout/copy the most recent revision, so I'm thinking of asking Omnis for an enhancement to allow copying out any revision from the VCS.  Then we would be able to cross reference check-in notes against our JIRA ticket system and decide which classes to move based on ticket status.



On Fri, Jan 26, 2024 at 9:14 AM <malkishtini at> wrote:

> Hi Paul,
> We are using a similar approach to Alax, we have 3 VCSs, dev, QA and 
> Production/Staging.
> New dev work will go to dev VCS, 2 weeks later move to QA and 2 weeks 
> later we replace the staging libraries with the QA build. When a bug 
> is reported in production, the change should be manually entered into 
> the 3 VCS. That was done in the Omnis 7 app.
> Now we converted to Studio, and we are in the process of building a 
> similar process for deploying the Studio product, so Studio is not yet 
> in production, but we must test it at some beta sites and the QA site, 
> so we made use of the OS11 VCS API.
> We built a nightly process that will move any unlocked classes from 
> dev to QA and production and then leave the new work in dev only (the 
> devs need to leave the classes checked out until they are done), of 
> course this approach has a limitation, but this is a temporary 
> solution until we can produce a better way to control VCSs.
> Then once the new feature is done to a leave that can be checked into 
> dev VCS, we add a flag/app pref to control when the new logic can be 
> executed and then we turn on that flag when the job is ready to be 
> released everywhere.
> Unfortunately, we are not close to using Git yet, because our Studio 
> libraries have issues that won't export to JSON and we don't have the 
> time to clean that up now.
> But Git will be a better option than VCS to handle branches if you are 
> able to use Git.
> I'm also interested to learn more about how others are handling 
> branching in their Omnis applications.
> Hope that helps,
> Mayada
> -----Original Message-----
> From: omnisdev-en <omnisdev-en-bounces at> On Behalf 
> Of Alex Clay via omnisdev-en
> Sent: Friday, January 26, 2024 6:55 AM
> To: OmnisDev List - English <omnisdev-en at>
> Cc: Alex Clay <aclay at>
> Subject: Re: VCS best practice for development vs production
> Hi Paul,
> We use release branches across all our projects, including Omnis. 
> Active work is done in main, and released at the end of each sprint 
> (every 2 weeks). There are three branches: a branch for main, a 
> staging branch we prep for final testing a few days before release, 
> and a production branch with the production code. Outside of Omnis we 
> also use feature branches for bug fixes and new work and merge them 
> with pull requests, but you'd need to use the JSON export/import to 
> manage your Omnis code and we're not there with Omnis.
> This release branch approach forces you to work in smaller chunks and 
> push that work to production much more frequently. This is a good 
> thing because it means your code is more production-ready and used 
> earlier and more often.
> When you have larger work that can't be deployed that often, use a 
> feature flag to disable it in production. This was you can build the 
> new window/system/framework/etc. and test and ship in pieces, but your 
> clients won't receive it until you have the whole feature ready and 
> flip the switch.
> You noted it wasn't possible to keep the big change separate from the 
> production code. Can you clone classes or use alternate libraries to 
> keep the legacy version intact and used in production while you 
> overhaul the rest? Then delete the legacy class when ready. Using an 
> adaptor patter, or some inheritance to retain design but swap implementation might help.
> With this release branch approach, if/when you need to hotfix a bug to
> production:
> 1) Make the change in the production branch
> 2) Deploy the fix from production
> 3) Copy the fix back to main
> When you get ready to stage your release or make your final release, 
> you overwrite your staging/production release with a copy of main or staging.
> In
> Omnis, this means you periodically replace the staging/production VCS 
> database with a copy of the main/staging VCS database. If you use git 
> to track other work (string tables, icon sets, htmlcontrols, etc.) 
> just merge the branches.
> Hope this helps!
> Alex
> > On Jan 26, 2024, at 04:40, Paul Mulroney
> <pmulroney at> wrote:
> >
> > 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       Trading as Logical
> Developments
> >                   ACN 161 009 374
> > Ph: +61 8 9458 3889                                       86 Coolgardie
> Street
> >
> > BENTLEY  WA  6102
> >
> >
> >
> > _____________________________________________________________
> > Manage your list subscriptions at Start 
> > a new message -> mailto:omnisdev-en at
> _____________________________________________________________
> Manage your list subscriptions at Start a 
> new message -> mailto:omnisdev-en at
> _____________________________________________________________
> Manage your list subscriptions at Start a 
> new message -> mailto:omnisdev-en at
Manage your list subscriptions at Start a new message -> mailto:omnisdev-en at 

More information about the omnisdev-en mailing list