VCS best practice for development vs production
Alex Clay
aclay at mac.com
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.
Alex
> On Jan 29, 2024, at 00:50, Paul Mulroney <pmulroney at logicaldevelopments.com.au> 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 gmail.com> 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 gmail.com> 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 lists.omnis-dev.com> On Behalf Of
>>> Alex Clay via omnisdev-en
>>> Sent: Friday, January 26, 2024 6:55 AM
>>> To: OmnisDev List - English <omnisdev-en at lists.omnis-dev.com>
>>> Cc: Alex Clay <aclay at mac.com>
>>> 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 logicaldevelopments.com.au> 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 logicaldevelopments.com.au Trading as Logical
>>> Developments
>>>> www.logicaldevelopments.com.au ACN 161 009 374
>>>> Ph: +61 8 9458 3889 86 Coolgardie
>>> Street
>>>>
>>>> BENTLEY WA 6102
>>>>
>>>>
>>>>
>>>> _____________________________________________________________
>>>> Manage your list subscriptions at https://lists.omnis-dev.com Start a
>>>> new message -> mailto:omnisdev-en at lists.omnis-dev.com
>>>
>>> _____________________________________________________________
>>> Manage your list subscriptions at https://lists.omnis-dev.com Start a new
>>> message -> mailto:omnisdev-en at lists.omnis-dev.com
>>>
>>> _____________________________________________________________
>>> Manage your list subscriptions at https://lists.omnis-dev.com
>>> Start a new message -> mailto:omnisdev-en at lists.omnis-dev.com
>>>
>> _____________________________________________________________
>> Manage your list subscriptions at https://lists.omnis-dev.com
>> Start a new message -> mailto:omnisdev-en at lists.omnis-dev.com
>
>
> “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 logicaldevelopments.com.au Trading as Logical Developments
> www.logicaldevelopments.com.au ACN 161 009 374
> Ph: +61 8 9458 3889 86 Coolgardie Street
> BENTLEY WA 6102
>
> _____________________________________________________________
> Manage your list subscriptions at https://lists.omnis-dev.com
> Start a new message -> mailto:omnisdev-en at lists.omnis-dev.com
More information about the omnisdev-en
mailing list