For what it's worth, I originally started with all of my SoapUI projects contained within the same project within GIT. At first, this made it really easy as I was the only one on the Test team, and it made sense. I was the source of truth and it made it a lot easier for me to just commit my work for the day once, instead of for 30 different projects.
Ultimately, it came to be one of the worst things I did. Developers had a hard time pulling down my projects due to how large they were. They didn't want everything, they just wanted the project for their service.
I ended up breaking every project out into individual git repositories and it was better, overall. It allowed for more flexibility and upkeep. There was a little more overhead, and I had to keep better track of how I committed, but in the end it ended up being much cleaner and straight forward to deal with. Not only for the developers, but for myself as well.
Hi msiadak,
Thanks for the response.
I see a big difference in having multiple projects versus multiple GIT repos. Agree that a test project should be kept as succinct as possible but we really should not be limited from having multiple independent projects in a single GIT repo.
From a .NET perspective, you can have multiple independent solutions in a GIT repo, developers simply pull down the solution they are interested in working on and do not need to worry about other solutions within the repo.
Having multiple repo's is a real nightmare when it comes to CI/CD. I want our test projects to live in the same repo as our actual APIs and have our CI/CD DTAP specifies as branches in the repo (feature specific, TST, Staging, PRD). When CI is running it can then deploy the APIs to the relevant target then on a separate task, pull the relevant test project associate to the API and execute the tests etc.
Having to jump to different repos is a real pain and it also does not keep control in the Continuous Delivery pipeline. At least IMO this is sub optimal and leads to much more overheads of trying to keep different repos in sync (e.g. the actual API delivery code and the related API test suites)
