VCS best practice for development vs production
Alex Clay
aclay at mac.com
Mon Jan 29 12:08:28 UTC 2024
Hi Paul,
"Release branches" is a naming convention, meaning they're named "release/approval" and "release/production" for our git-based repos.
We use our own customized version of the Omnis VCS in conjunction with OmnisCLI and a Jenkins build system to produce libraries from the VCS database, then build installers and test everything with OmnisTAP. There are build jobs for the different branches, each of which uses a specific VCS database.
Others have mentioned using different Omnis VCS database for branching so I expect it's possible to effect branching that way. :)
Alex
> On Jan 29, 2024, at 00:17, Paul Mulroney <pmulroney at logicaldevelopments.com.au> wrote:
>
> HI Alex,
>
> Thanks for your feedback!
>
> When you say "release branches", are you using the Omnis VCS? How are you achieving your branches?
>
> Regards,
> Paul.
>
>
>> On 26 Jan 2024, at 7:54 pm, Alex Clay via omnisdev-en <omnisdev-en at lists.omnis-dev.com <mailto:omnisdev-en at lists.omnis-dev.com>> wrote:
>>
>> 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 <mailto: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 <mailto:pmulroney at logicaldevelopments.com.au> Trading as Logical Developments
>>> www.logicaldevelopments.com.au <http://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 <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 <https://lists.omnis-dev.com/>
>> Start a new message -> mailto:omnisdev-en at lists.omnis-dev.com
>
>
> A man rushed into the doctor’s office and shouted, “Doctor! I think I’m shrinking!”
> The doctor calmly responded, “Now, settle down. You’ll just have to be a little patient.”
> --
> Paul W. Mulroney We Don't Do Simple Pty Ltd
> pmulroney at logicaldevelopments.com.au <mailto:pmulroney at logicaldevelopments.com.au> Trading as Logical Developments
> www.logicaldevelopments.com.au <http://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