VCS best practice for development vs production

Paul Mulroney pmulroney at
Mon Jan 29 05:50:21 UTC 2024

Hi Alan,

Thanks for your feedback!

That sounds like a clever idea - we use MantisBT for our issue tracking, and we also use the mantis reference number in our code.  I could see us being able to do something similar with this setup.


> On 26 Jan 2024, at 10:21 pm, Alan Davey <david.a.davey at> wrote:
> 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.
> Regards,
> Alan
> 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 

“We are what we repeatedly do. Excellence then, is not an act, but a habit.”
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

More information about the omnisdev-en mailing list