VCS best practice for development vs production

Paul Mulroney pmulroney at
Mon Jan 29 23:12:58 UTC 2024

Hi Alex,

It's certainly food for thought - I'll look into Jenkins.


> On 29 Jan 2024, at 7:48 pm, Alex Clay via omnisdev-en <omnisdev-en at> wrote:
> 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.
> Alex
>> 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.

I saw an ad that said "Radio for sale. $1. Volume stuck on full"
I thought "I can't turn that down"!
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