Should You Keep All Your Artifacts in the Same Repository?
I was surprised to read a number of threads in online discussions recently in which people who came mainly from a software testing background were just coming around to the idea of keeping their test scripts in the same source repository as the production application code. The discussions were inspired by an article by test automation specialist Angie Jones.
I learned that testers and test automation specialists have long maintained test scripts separately, based on the idea that the test scripts and the application code are two different things. It had never occurred to most of them to maintain test scripts and application code in the same repository.
In the same discussion threads, people who came mainly from a programming background repeatedly stated that it was normal and preferable to keep all product artifacts together, based on the idea that the product is one thing. It had never occurred to most of them not to keep test scripts and application code in the same repository.
In fact, the idea of keeping product artifacts together doesn’t end with test scripts. Every type of artifact that pertains to the product ought to be maintained together and versioned together. Doesn’t it make sense to check out the version of a server provisioning script that goes along with a given version of the application code, and the corresponding version of the end user documentation, and the corresponding version of the test cases? Why wouldn’t you do that?
Motion
One of the canonoical Lean wastes is motion. It refers to the movements of workers when they change tools or perform tasks. In a lean manufacturing cell, the most frequently-needed tools are near to hand, often kept in a shadow box so that each tool can always be found in exactly the same place, every time a worker needs it. Similarly, any parts or subassemblies consumed by that cell are close by, to minimize the motion necessary to find things and move them into position to work on them.
The analogous principle for software delivery is to have all the electronic artifacts necessary organized and stored in a way that makes them readily available to team members who need them. It should be possible to check out a project from version control without worrying that you then have to chase down various artifacts in multiple data stores, like wikis, SharePoint sites, shared network drives, test tools, or (shudder) copying them from production servers. When you check the project out of version control, you have everything you need to work on it.
But Still…
That said, the question “Why wouldn’t you do that?” isn’t rhetorical. Some solutions may have practical limitations that preclude it. On the other hand, in many cases when people say it’s not feasible, it’s because they haven’t thought outside the box about it.
For instance, consider a solution that has mobile components on iOS and Android, embedded code for IoT devices, a web front end written in, say, React.js or even a more conventional stack like Java or C#, a mid-tier piece hosted on an application server such as IBM WebSphere or jBoss, and a back-end piece running on IBM zOS or HP NonStop.
Is it even possible to maintain the sources for all those components, plus test suites, plus configuration and provisioning scripts, plus documentation, in a single version control repository? It may be possible, but it certainly isn’t what people are accustomed to doing. Besides that, it may not be optimal if multiple development teams are involved, they tend to work in isolation from one another most of the time, and they may be located remotely from one another.
Conclusion
There are potentially both real and perceived reasons why all artifacts can’t be managed in a single repository. Yet, in most cases it’s quite feasible and beneficial to do so. It’s worth the effort of reasoning through the details of your situation to try and minimize motion for your development teams. You may discover it’s feasible in more cases than you thought.