VCS best practice for development vs production

Alex Clay aclay at
Mon Jan 29 11:48:49 UTC 2024

Hi Paul,

We do the same as Alan with our Jira issues—move them to a testing status upon a successful build. I would strongly recommend looking at a build system like Jenkins to manage all this coordination and keep track of builds. No need to re-invent a wheel—just add the unique bits for Omnis and for your organization.


> On Jan 29, 2024, at 00:50, Paul Mulroney <pmulroney at> wrote:
> 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.
> Regards,
> Paul.
>> 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.”
> Aristotle
> -- 
> 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

More information about the omnisdev-en mailing list