Are there any plans to improve this? It’s lacking some major functionality present in Jenkins.
1. You can’t define the pipeline in code and handle changes to the pipeline through normal code-review + merge processes.
You can store project settings in source control, but this specifically does not handle snapshot-dependencies. Additionally, while it stores the settings, they’re not friendly to read/edit as there is no documentation about all possible values and what they mean. You’re stuck editing in the UI, but the UI can only edit things that go to the default branch.
The update to support Kotlin is nice in that it gives a way to error check and tab completion, but I still can’t find any decent documentation on what the objects/properties actually do. Sometimes it’s clear from the name, but often it is not. You’re still stuck editing something in the UI in a test project, exporting it to Kotlin format, and examining it to figure out what are valid values or doing trial runs to determine actual behavior.
2. The pipeline is a byproduct of a series of dependencies, it’s not a first-class item. You have to know to dig into specific configurations and then have to dig through multiple tabs to get information on the pipeline. it’s also a byproduct of multiple configurations requiring coordinated editing across them, which again requires making changes in the GUI, not in source control.
3. Painful to do mixed branches. If you have a set of merge requests in multiple repositories for different parts of the pipeline, it’s impossible to do a build using those unless you manually kick off each individual part of the process and force it to use specific dependencies. It only works if what you want is default + a branch named identically in all repositories.
Because TeamCity doesn’t have these, especially #1, we’re considering other options and may be migrating away from TeamCity. Thus far it seems unlikely that any of these will be added to TeamCity any time soon.
If a future update allowed for defining a complete pipeline in code similar to Jenkins and there was full documentation on that format, then I’d think TeamCity was competing on pipelines.