1

We have started trying to move toward CI and automation. There's not a lot of cross-talk between teams, and I've discovered that many have developed simple or sophisticated build & test scripts, all in the same language (Python).

None of them have any mutual Git history or significant amount of copied code, but all implement at least a certain set of features (build a .sln, prep the target device, run built executable on the target device, etc).

We all have been taught the evils of duplicate code, but what about duplicate features and redundant programs?

Should I try to merge or re-use these scripts? There are a handful of them, so it seems daunting. How can I determine the cost/benefit?

If I do decide to merge/re-use, what are some good strategies or best practices for combining repos like this? I'm thinking maybe my best first step is to make one of them into a modular/generic library.

1

I'd recommend establishing a command interface for your repositories.

eg:

 go build 1.2.3.4           #builds the binaries into a directory
 go test                    #runs developer orientated tests (like unit tests)
 go deploy path/to/config   #takes the directory and deploys it, configuring the deployment and machine environment
 go acceptance              #runs the business orientated/integrated environment tests on a deployed test instance
 go publish                 #takes the directory of built binaries, packages it and publishes it to a binary repository
 go get 1.2.3.4             #retrieves the exact versioned package from the binary repository

It does not matter how go is implemented (or whatever other name you use) as long as its in the root of the repository, and can be run be as a command by /path/to/repo/go args.... This way your CI tool, and developers can easily start using any code repo.

You can pursue any standardisation efforts from there. As you've no doubt noticed some things would be better built once, and then used as a build dependency.

However fair warning try not to over standardise, you will only paint yourself into a corner. Leave room for each repo to change its tooling, use different versions, or methodologies for the same effect. This is the main reason for having a repo interface in the form of a command and argument set that is common, but allowing variety in extra commands, or implementation details.

0

I am assuming that the entire codebase, though in different repositories exist on a single platform like git. If not please first put them in one platform.

IMO brainstorming should be the first step to decide which features are redundant and can be exported to a common codebase and then used by all. Since the redundant features possibly could be using different set of input and output, a decision would be required to standardise the input and output as well as the format. An adapter would be really beneficial here which could initially help to interact with the common code (destination) without changing much of the the source.

Plus you can have multiple endpoints to expose your common features which could be used in different ways. Once the common features are usable and in production the redundant codebase can be removed altogether. Hopeful that this will help to resolve few unanswered questions.

0

If you are just talking about build and test scripts, then there is really not much reusable code. Project and solution files all have different names and paths. It seems like duplicated code, but creating generic build scripts and test harnesses means adding yet another layer of abstraction. You would still need to write build and test scripts that call your generic build and test scripts so they can pass in the right paths. You aren't really gaining anything.

1
  • Are you suggesting that it's better to use hard-coded filepaths than to accept filepaths as arguments? – cowlinator Aug 22 '19 at 23:09
0

There's not a lot of cross-talk between teams

This is important here. You need to solve a problem. What does standardization brings you? Do you have people complaining that they're moving between five different projects and have to remember seven different scripts? Then it might be worthwhile to standardize the most common commands that the cross-project people need to do.

Is it only the CI system that have implement different configurations for different project? Then you might not need full standardization, you'd want to think what the CI tool need out of each project and implement a common interface for those commands. If your CI system need to run a build and test command, implement those. Does your CI tool not need to run individual subtest? Then implementing that is probably not needed.

If you decide to standardize, don't worry about standardizing implementations, especially if your projects are using a heterogenous set of tech stack. Standardizing implementations can make it harder for each project to evolve, as each change has to consider the impact on other projects. Don't solve a problem that you don't have. Instead standardize the interface instead.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.