Currently, I have automation scripts running in Copado Robotic Testing in SIT and UAT. I have 4 branches that is setup in Github in following way. So under main repo, the following branches are setup. Branch A - English Markets*(same branch used for 4 English Markets as the functionalities are same for these markets)*
Branch B - Non English Markets (same branch used for 3 Non English markets as the functionalities are same for these markets)
Branch C - Korea Market (runs only Korean scenarios and cannot be clubbed with above as the functionalities are different)
Branch D- Smoke Testing
At present, I have this 4 branches common for both SIT and UAT.
Our release structure is 3 weeks , SIT and UAT testing timelines are completely different and do not overlap each other. so no problem using same branch.
Currently, release team is migrating to one week cycle (Every week to production) , so SIT and UAT build will overlap each other. Meaning the build in SIT is always not available in UAT since it is still in SIT testing phase. In theory, SIT code is ahead of UAT. Not everything in SIT should go to UAT within one week of sprint, SIT and UAT may share 3 PBI’s common as they are deployed until UAT but there could be 2 PBI’s still in SIT and not in UAT - This is my problem
In this 1 week release cycle. I should perform both SIT and UAT testing with the code/build different from each other.
I think having separate 5 branches for UAT is not meaningful considering maintenance efforts and other challenges, Can someone advise/share their experience. Many thanks in advance.
Hi @skisuluv . Welcome to the community, the most awesome QA community in the universe.
I think, people are not quite getting your context, or are afraid to just reflect and give an opinion. I will try at least anyway.
I have no idea what Capodo robot is, but I assume it is a tool you have bought or downloaded. I’m also not sure what SIT stands for, do you mean Software-Integration-Testing? If so, then you probably have an unusual SDLC ( Systems development life cycle - Wikipedia ) , because many teams use the word integration not as a “phase”, but as a continous activity that never actually “ends”. Either way, I get the idea. But you seem to be using branches to keep targets separate for each language. I think your branches are an artefact of the software lifecycle and process in the company, and are not actually version-control branches in the classic sense of the word, but are temporary buckets rather for meta-data… sorry a bit confusing. But.
Basically your issue is that you have 5 branches and those feel like too much to track and get your head around. Well surprise time, 5 branches it not that many. The reason you are struggling is because the branches are all being treated as completely separate pieces of work and not as copies of a template. If you step back you will find a lot of duplication, and my take would be to write a workflow description that describe all 5 branches as if they are all the same. Because they essentially are, the only differences are their maturity and WHO they deliver or PUBLISH to? If this makes sense to you and is a possible way forward, let me know, If not, let me know also, yes I know it is hard. But you got hired to do this job, because you are able to ask hard questions and to solve hard problems. We can do this.