suggestions: bulk edit parameters and extend build configuration template
After using TeamCity for around a year now for deploying around +- 15 applications, I can say I'm very happy with our choice for TeamCity.
It's easy to understand, and there are very few limitations on what can be achieved with the build configurations.
However, I would like to suggest these 2 features:
1. Allow bulk edit of configuration parameters (for multiple configurations at once). The inheritance system is great, and it would be even better if it's possible to show (and edit) all of the parameters for the entire tree in one (giant) screen.
2. Extend build configuration templates. We are using one build configuration template for all our (Symfony) apps. And some build steps are specifically for one app, but are now defined in the main build configuration. Because we also use 6 configurations for each app (for deploying to 3 staging servers, 3 production servers). And you don't want to duplicate a build step for those 6 configurations. So we use parameters to define which steps are executed for which applications.
I know there is the "extract meta runner" feature, but that feels like a major step in complexity that we would like to avoid.
And in my mind, with all the inheritance going on already in TeamCity, extending build configurations wouldn't be too much work to support?
Please sign in to leave a comment.
thanks for the suggestions. About 1, there isn't much I can share right now but we appreciate the input. This said, adding something like this can be problematic in many instances. For somewhat small build chains this is reasonable, but as they grow big, this would eventually create a rather unmanageable list, with many properties repeated throughout the display since properties are inherited within a project. If you have a list of properties you want to see, you can always define them explicitly or reference them via the "dep.." syntax. You can also reference them at the end of the chain with "reverse.dep.." for overriding them. This would allow you to create a list of "relevant" properties that you can check and override if needed, but still would need to be curated manually.
I've created a feature request for your suggestion here: https://youtrack.jetbrains.com/issue/TW-82429/Allow-managing-parameters-for-the-whole-chain-from-the-edit-parameters-page-of-a-build-config-involved-in-the-chain - Please feel free to vote for it.
About your second one, this is going to be more complicated and I would say that meta runners should be the go-to option here, as that's what they intend to do to for the most part. I can understand that they seem like some work at first, but it's actually quite simple If you extract a meta runner you really don't need to take care of pretty much anything else, it should be as simple as it gets. Modifying it can be done through the XML but you can always just keep the base reference, modify it in the UI, reextract and replace the meta runner. It's a couple extra steps but unless you are constantly performing changes to the builds themselves, it shouldn't cause much of an overhead.
With this in mind, we do have a feature request for composite templates: https://youtrack.jetbrains.com/issue/TW-12153/Build-template-nested-meta-template
Of course, both things can be simplified even further by using the Kotlin DSL but that does have a steeper learning curve.
thanks for the suggestions. About 1, there isn't much I can share right now but we appreciate the input. This said, adding something like this can be problematic in many instances. For somewhat small build chains this is reasonable, but as they grow big, this would eventually create a rather unmanageable list, with many properties repeated throughout the display since properties are inherited within a project. If you have a list of properties you want to see, you can always define them explicitly or reference them via the "dep.." syntax. You can also reference them at the end of the chain with "reverse.dep.." for overriding them. This would allow you to create a list of "relevant" properties that you can check and override if needed, but still would need to be curated manually.
I've created a feature request for your suggestion here: https://youtrack.jetbrains.com/issue/TW-82429/Allow-managing-parameters-for-the-whole-chain-from-the-edit-parameters-page-of-a-build-config-involved-in-the-chain - Please feel free to vote for it.
About your second one, this is going to be more complicated and I would say that meta runners should be the go-to option here, as that's what they intend to do to for the most part. I can understand that they seem like some work at first, but it's actually quite simple If you extract a meta runner you really don't need to take care of pretty much anything else, it should be as simple as it gets. Modifying it can be done through the XML but you can always just keep the base reference, modify it in the UI, reextract and replace the meta runner. It's a couple extra steps but unless you are constantly performing changes to the builds themselves, it shouldn't cause much of an overhead.
With this in mind, we do have a feature request for composite templates: https://youtrack.jetbrains.com/issue/TW-12153/Build-template-nested-meta-template
Of course, both things can be simplified even further by using the Kotlin DSL but that does have a steeper learning curve.