How to reduce duplication of similar build configurations? - teamcity

Question

I have several projects that I'd like to have in separate build configurations with slightly different configurations:
VCS source and build triggers (i.e. the only difference is which subdirectory of the projects root dir to use)
build steps (the first few are the exact same, but the last few may vary depending on how the unit tests are to be run, dependencies, etc.)
That's it. I looked into Build Configuration Templates, but it seems that does not allow the flexibility of specifying custom build steps or extra VCS roots.
Really I'm just looking to not have to manually copy the (several) build steps from our initial project's build configuration into several more configurations, and to have to maintain them all when things change. It seems there should be a better solution?

Answer 1

I've wondered this as well, but the bits I've found online suggest you favor the redundancy instead of trying to reuse one configuration across your multiple branches or projects.
However, all of that was before version 8 was released, which introduces the ability to extract a meta-runner
Their blog from April 13, 2013 provides a good summary of what they are and how they differ from templates.
Meta-runner
Meta Runner is a powerful feature providing a promising new way for customizing TeamCity and making it even more people-oriented. To understand it, let’s consider an example.
Imagine you have some repeated task used over and over again across different build configurations. The task is defined as one or more build steps, based on built-in runners, like Ant or command line. Most likely you’d want to reuse this task easily across several build configurations. You can’t do this with templates because template enforces you to share the same settings across different configurations which is not always possible. A solution which we propose is to extract Meta-runner out of these steps, see how it works in release notes.
I have yet to implement this, but I will be testing it out soon. It makes me think that you should be able to pass the repository in as a parameter, but I am not sure.

Answer 2

I've been struggling with this for a while and developed a tool to manage it, I call it Dictator Builder.
For a long time, we have been working with "template"-projects. Basically it is a repository that has a fully working application complete with all build configurations needed. Much like react-boilerplate is. We have several template projects, one for each type of application we develop.
Problem with this is keeping copied code in synk with the template project.
I now have the template code packaged within a "dictator". Like this:
https://github.com/tomasbjerre/dictator-react-boilerplate/tree/master/dictatables/static-files/react-boilerplate
The dictator dictates that some static files should be copied to the root of a dictated folder.
{
"message": "Copy react-boilerplate",
"actions": [
{
"copyFrom": "react-boilerplate",
"target": "."
}
]
}
The dictator can be run from command line like npx dictator-react-boilerplate#version. It will dictate the current working directory, typically your code base in an application. It can be configured by the code base in a .dictatorconfig.json file. Perhaps choose not to be dictated on some parts:
{
"ignore": [
"/app",
"/package.json",
"/package-lock.json",
"/Changelod.md"
]
}
So that most of the build configuration from the template is just copied to the dictated code base. And the app folder, and other things, are still managed by the code base.
When cloned, the folder looks like:
app
coverage
.dictatorconfig.json
docs
.gitignore
internals
LICENSE.md
node_modules
package.json
README.md
server
And after npm install, or after npx dictator-react-boilerplate#version it looks like:
.all-contributorsrc
app
appveyor.yml
babel.config.js
Changelog.md
CODE_OF_CONDUCT.md
CONTRIBUTING.md
coverage
.dictatorconfig.json
docs
.editorconfig
.eslintrc.js
.gitattributes
.gitignore
internals
jest.config.js
LICENSE.md
node_modules
.nvmrc
package.json
package-lock.json
.prettierignore
.prettierrc
README.md
server
.stylelintrc
.travis.yml