VCS best practice for development vs production
Paul Mulroney
pmulroney at logicaldevelopments.com.au
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.
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
More information about the omnisdev-en
mailing list