VCS best practice for development vs production

Alan Davey david.a.davey at gmail.com
Fri Jan 26 14:21:11 UTC 2024


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
>


More information about the omnisdev-en mailing list