VCS best practice for development vs production

malkishtini at malkishtini at
Fri Jan 26 14:14:30 UTC 2024

Hi Paul,
We are using a similar approach to Alax, we have 3 VCSs, dev, QA and
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

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,
-----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

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!


> 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,
> 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
> 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 

More information about the omnisdev-en mailing list