VCS best practice for development vs production

[malkishtini at gmail.com]

Hi Rob,
Yes, we automated the build from one VCS database and checking them into
another VCS database using the OS11 VCS AP along with Alex's Omniscli tool.

Then we use a Windows scheduled task to run a batch file that will run
different commands in sequence to execute the build and deployment processes
that we have built so far.
I.e., no manual interaction in the process.

Hope that helps,
Mayada

-----Original Message-----
From: omnisdev-en <omnisdev-en-bounces at lists.omnis-dev.com> On Behalf Of
Paul Mulroney
Sent: Monday, January 29, 2024 12:48 AM
To: Omnis-dev list <omnisdev-en at lists.omnis-dev.com>
Subject: Re: VCS best practice for development vs production

Hi Mayada,

Thanks for your feedback!  When you say you're using the OS11 VCS API, did
you need to write some code somewhere that managed the transfer from one VCS
to the other, or is that a manual process?

Note to self: find out about this Studio 11 VCS API...

Regards,
Paul.


> On 26 Jan 2024, at 10:14 pm, 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



The nurse came in and said to the doctor "There's a man in the waiting room
who thinks he's invisible, what should I tell him?"
The doctor said "Tell him I can't see him today."
-- 
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