VCS best practice for development vs production

[Paul Mulroney]

HI $all

Mayada and others have talked about automating the build process, and everyone also mentions that they have their own custom code to help facilitate the process.

Is it common enough that perhaps it should be built into the Omnis VCS system?  What's considered "Best Practice" in this regard?  Taking everyone's input, is it possible to put together a checklist of features/practices that are regarded as the ideal setup for version control in Omnis?

For example:
- One version control system
- Staged builds eg Development/Testing/Production.  Achieved by multiple VCS or a version control system that supports branches eg git or SVN
- Automated builds
- Integrating Bug/Issue tracker (eg Jira/Mantis etc) so that when an issue is resolved it can be tracked within the VCS and affected classes promoted/transferred from the Dev to Testing "branches".  This should be an automated process
- Avoid double entry of code eg don't code twice (principle: DRY - don't repeat yourself) 
- Avoid manual processes
- Automated testing to verify successful integration into test/production

The theory is that if we follow this checklist of best practice, then we minimise the risk of buggy code making it into production.  Does this make sense?

Regards
Paul.


> On 29 Jan 2024, at 9:35 pm, malkishtini at gmail.com wrote:
> 
> 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
> 


This is my step ladder. I never knew my real ladder.
-- 
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