Making TeamCity easier, more likely to succeed quickly

Hello

I've used TeamCity at most contracts I've worked at but it’s always already been setup. At this job, its installed and they've wanted to get it working for 18 months. I have come along and am also not getting much success fast, I have gotten two tiny projects setup but the big stuff is a struggle. I've personally struggled with it for 9 months. I spent weeks writing a file copy system for deploying files to Linux (from the Windows TC box) with rollback mechanism because there's no transactional Linux filecopy task in TC.

I'm not ashamed to admit I struggle with TC. I'm a very technical programmer, I'm a former Microsoft support engineer, I have an IQ ~148 but I find TeamCity really hard work. I actually think it’s a very good piece of software and I recommend it to people. When it’s working, its superb, the support is great and the dev team seem to really care about making a great product. But I'm also a strange programmer; I don't seem to see things how other people do. I'm not nerdy about anything other than the code in the software I'm writing - I don't care or want to learn TeamCity, like I don't want to learn how my microwave oven works, I just want hot food.

Programmers I've met tend to be concerned with nerdy details, they blame end-users for being stupid, not themselves for being unable to empathise and build useable software. They seem to want to expose the complexity of a product to show how clever they have been to build it in the first place. This has changed in the last decade since UX, interaction designers and Agile processes have come in, but where programmers build apps for other programmers, they tend not to remember that other programmers are just users, concerned only with getting their jobs done and remaining in a good mood.

TeamCity mostly fills me with dread. Even my project managers de-emphasise any TC stories in the backlog because they've learnt that they just eat very expensive developer/consultancy time and delivery very little. Although I can see that you've really tried with this product, I regret to say that it's still very hard to succeed with it.

What's more, I don't really know how this is so, considering that I mainly want to do the same thing with it every time. That is, I think there are maybe 10 main, popular 'recipes' that a .NET team would need. Likewise for Java. Most of them will be something like, Setup with source control > Build some project/product/site/service in some configuration > Test it > Deploy or package it. I think some of the hand-holding/wizard setup falls down because there's no mechanism for TC to read the repo/code/project-files and offer options and help during setup, it’s all trial and error. Often, the details of MSBuild are exposed - and that's a problem because (Microsoft certainly) programmers only know F5 = running app, how Visual Studio does this is just magic that's rarely needed to be learned. It's not lazy, we just don't need to know.

So often I'll be confronted with all sorts of problems I don't understand and will involve hours of reading about MSBuild, which I could avoid if I just wrote a macro in VS2012 and hosted it like a build server (my point is, stuff breaks on TC that doesn't in VS). I cost my client a lot of money, so they aren't getting good value - they're not getting new features or insights in their product for their business. If there was a TeamCity man I could call out to set this up, I would, like a plumber. Money well spent.

Today, for instance, I setup a simple test build of a solution. The solution has two websites, it uses NuGet packages (external and internal via TC) and a bunch of dependent library projects, one of which is a .NET Portable lib. It builds in VS2012 but it just gives me a list of 100s of errors from a simple 'Build sln file' TC build step:


Hypermedia\RelatedLinkCollection.cs(14, 6): error CS0246: The type or namespace name 'CollectionDataContractAttribute' could not be found (are you missing a using directive or an assembly reference?)

... Almost the same error over and over ...

Mathematics\SpatialVector.cs(49, 35): error CS0234: The type or namespace name 'DataContract' does not exist in the namespace 'System.Runtime.Serialization' (are you missing an assembly reference?)
Mathematics\SpatialVector.cs(49, 35): error CS0234: The type or namespace name 'DataContractAttribute' does not exist in the namespace 'System.Runtime.Serialization' (are you missing an assembly reference?)
Project CompanyNamePortableCore\CompanyNamePortableCore.csproj failed.
Project WebCore\WebCore.csproj failed.
E:\TeamCity-BuildAgent\work\62023563850993a7\Web\.nuget\nuget.targets(88, 9): Unable to find version '1.0.17.0' of package 'MarkLogicManager40'.
E:\TeamCity-BuildAgent\work\62023563850993a7\Web\.nuget\nuget.targets(88, 9): error MSB3073: The command ""E:\TeamCity-BuildAgent\work\62023563850993a7\Web\.nuget\nuget.exe" install "E:\TeamCity-BuildAgent\work\62023563850993a7\CompanyNameImagesMvc\packages.config" -source ""  -RequireConsent -solutionDir "E:\TeamCity-BuildAgent\work\62023563850993a7\Web\ "" exited with code 1.
Project CompanyNameImagesMvc\CompanyNameImagesMvc.csproj failed.

... etc. etc. more of the same ...



The project uses a NuGet package from TeamCity (one of the two successfully running TC projects). I don't know why it can't find this 1.0.17.0 version. My VS works.

And of course, why it can't find 100s of standard .NET types I have no idea, again, it builds find on all our machines. I just don't understand how a simple solution can just fail to build like this? I fear using TeamCity. I know I'm going to go from failure to failure all day and face grillings from my boss/client at every stand-up.

I don't even know if building the whole solution will be what I should be doing anyway. My objective is to create a QA MSDeploy package for just one of the projects in the solution. That's all and I think that's a 'top 10' use case. Would it be possible to have 'recipes' or templates based around use-cases? Would it be beneficial to check out the repo and read and process the solution and project files and have the UI offer better guidance? Or maybe use a VS add-in and the VS API to read the list of projects and build configurations etc. and have a TC UI in VS that writes the correct config to TeamCity?

I don't know. But I did want to feedback how hard I think TC is to use and why we are yet to buy a license. I also want to add that this friction is why Azure, TFS and cloud build and deploy is what I use for my own personal apps. I just want a microwave that gives me hot food and I don't care who makes it.


Luke

Message was edited by: Yegor Yarko (returned newlines back)

5 comments
Comment actions Permalink
Great - what happened to my carriage returns. I wrote all that and now no one is going to read it.
0
Comment actions Permalink

Hello

I've used TeamCity at most contracts I've worked at but its always already been setup.
At this job, its installed and they've wanted to get it working for 18 months. I have come along and am also not getting much success fast, I have gotten two tiny projects setup but the big stuff is a struggle.

I've personally struggled with it for 9 months. I spent weeks writing a file copy system for deploying files to Linux (from the Windows TC box) with rollback mechanism because there's no transactional Linux filecopy task in TC.

I'm not ashamed to admit I struggle with TC. I'm a very technical programmer, I'm a former Microsoft support engineer, I have an IQ ~148 but I find TeamCity really hard work.

I actually think its a very good piece of software and I recommend it to people. When its working, its superb, the support is great and the dev team seem to really care about making a great product.

But I'm also a strange programmer; I don't seem to see things how other people do. I'm not nerdy about anything other than the code in the software I'm writing - I don't care or want to learn TeamCity, like I don't want to learn how my microwave oven works, I just want hot food.

Programmers I've met tend to be concerned with nerdy details, they blame end-users for being stupid, not themselves for being unable to empathise and build useable software. They seem to want to expose the complexity of a product to show how clever they have been to build it in the first place. This has changed in the last decade since UX, interaction designers and Agile processes have come in, but where programmers build apps for other programmers, they tend not to remember that other programmers are just users, concerned only with getting their jobs done and remaining in a good mood.

TeamCity mostly fills me with dread. Even my project managers de-emphasise any TC stories in the backlog because they've learnt that they just eat very expensive developer/consultancy time and delivery very little.

Although I can see that you've really tried with this product, I regret to say that it's still very hard to succeed with it.

What's more, I don't really know how this is so, considering that I mainly want to do the same thing with it every time.

That is, I think there are maybe 10 main, popular 'recipes' that a .NET team would need. Likewise for Java.

Most of them will be something like,
Setup with source control
> Build some project/product/site/service in some configuration
> Test it
> Deploy or package it.

I think some of the hand-holding/wizard setup falls down because there's no mechanism for TC to read the repo/code/project-files and offer options and help during setup, its all trial and error.

Often, the details of MSBuild are exposed - and that's a problem because (Microsoft certainly) programmers only know F5 = running app, how Visual Studio does this is just magic that's rarely needed to be learned. It's not lazy, we just don't need to know.

So often I'll be confronted with all sorts of problems I don't understand and will involve hours of reading about MSBuild, which I could avoid if I just wrote a macro in VS2012 and hosted it like a build server (my point is, stuff breaks on TC that doesn't in VS).

I cost my client a lot of money, so they aren't getting good value - they're not getting new features or insights in their product for their business. If there was a TeamCity man I could call out to set this up, I would, like a plumber. Money well spent.

Today, for instance, I setup a simple test build of a solution. The solution has two websites, it uses NuGet packages (external and internal via TC) and a bunch of dependent library projects, one of which is a .NET Portable lib. It builds in VS2012 but it just gives me a list of 100s of errors from a simple 'Build sln file'

TC build step:Hypermedia\RelatedLinkCollection.cs(14, 6): error CS0246: The type or namespace name 'CollectionDataContractAttribute' could not be found (are you missing a using directive or an assembly reference?) ... Almost the same error over and over ...Mathematics\SpatialVector.cs(49, 35): error CS0234: The type or namespace name 'DataContract' does not exist in the namespace 'System.Runtime.Serialization' (are you missing an assembly reference?) Mathematics\SpatialVector.cs(49, 35): error CS0234: The type or namespace name 'DataContractAttribute' does not exist in the namespace 'System.Runtime.Serialization' (are you missing an assembly reference?) Project CompanyNamePortableCore\CompanyNamePortableCore.csproj failed. Project WebCore\WebCore.csproj failed. E:\TeamCity-BuildAgent\work\62023563850993a7\Web\.nuget\nuget.targets(88, 9): Unable to find version '1.0.17.0' of package 'MarkLogicManager40'. E:\TeamCity-BuildAgent\work\62023563850993a7\Web\.nuget\nuget.targets(88, 9): error MSB3073: The command ""E:\TeamCity-BuildAgent\work\62023563850993a7\Web\.nuget\nuget.exe" install "E:\TeamCity-BuildAgent\work\62023563850993a7\CompanyNameImagesMvc\packages.config" -source ""  -RequireConsent -solutionDir "E:\TeamCity-BuildAgent\work\62023563850993a7\Web\ "" exited with code 1. Project CompanyNameImagesMvc\CompanyNameImagesMvc.csproj failed. ... etc. etc. more of the same ...

The project uses a NuGet package from TeamCity (one of the two successfully running TC projects). I don't know why it can't find this 1.0.17.0 version.

My VS works.And of course, why it can't find 100s of standard .NET types I have no idea, again, it builds fine on all our machines. I just don't understand how a simple solution can just fail to build like this.

I fear using TeamCity. I know I'm going to go from failure to failure all day and face grillings from my boss/client at every stand-up.

I don't even know if building the whole solution will be what I should be doing anyway. My objective is to create a QA MSDeploy package for just one of the projects in the solution.

That's all and I think that's a 'top 10' use case.

Would it be possible to have 'recipes' or templates based around use-cases?

Would it be beneficial to check out the repo and read and process the soution and project files and have the UI offer better guidance?

Or maybe use a VS add-in and the VS API to read the list of projects and build configurations etc. and have a TC UI in VS that writes the correct config to TeamCity?

I don't know. But I did want to feedback how hard I think TC is to use and why we are yet to buy a license. I also want to add that this friction, for me personally, is why Azure, TFS and cloud build and deploy is what I use for my own personal apps. I just want a microwave that gives me hot food and I don't care who makes it.

Luke

I read it and reformatted for you :)

I have only ever used the Java side of things but I find it very straighforward to do and much easier than other continuous build systems (try and configure the xml in CruiseControl!)
e.g. I just add a build step that points to the build script and specifies the target and away I go.

I wonder if it is due to you using .NET.
In Java you often end up with two build systems. The build script (e.g. ant/maven/gradle etc) that can be run externally of the IDE and the built in IDE build.
The latter is just enough to compile and debug your code but the former would include steps to run the official test suite and deploy the code etc.


This could be down to the perspective of a what a Visual Studio developer considers 'normal' and 'expected work' vs what a Java developer would.
Since the Java developers don't often have some of the Visual Studio magic that you mention in their day to day, then configuring TeamCity doesn't seem like such an effort.

None of this helps your issues though :)

0
Comment actions Permalink

Hi Luke,

Thank you for the feedback.
(I also edited your original post to insert the newlines, sorry for the issue.)

I think I understand the main point and your post is definitely something to match some of our future features against.

Also, here are some comments:

You are right that TeamCity does not solve the "how to build the software" problem. It kind of assumes people know how to build and then it does provide orchestration facilities as well as it uses understanding for some of the build tools out there to present results in a more smart manner then just failed/passed flag. It also tries to solve most common problems while going from "it works on one machine" to "let's scale into a build farm and share the current project status with the team".

You are also right that many people would prefer "one button" solution over getting access to the flight instruments of an aircraft. Our experience shows, however, is that there is little unification of the build processes across the different companies and unless there is a vendor forcing a single "right" solution from top to bottom, no silver bullet one button solution seem to exist.

That being said, of course there is still huge room for improvement. It might be appropriate to imagine TeamCity (in it's current state) as a core which might require specific "plugs" to target specific use cases. And that is indeed can be achieved by TeamCity plugins. We will of course write those ourselves, but with the number of technologies out there we could not cover them all. The good news is that everybody could write their own plugin for that. Not so good might be that TeamCity plugins are to be written in a JVM language with Java interoperability (Java, Groovy, JRuby, Kotlin, etc.)

We would appreciate detailed descriptions of the use cases and details on what would you expect TeamCity to do for solving the tasks you consider generic ones.
These might be better posted separately, as forum threads or as issues in the issue tracker.

0
Comment actions Permalink

Hi Yegor, thanks for your response (and the other dude for reformatting).

The plugin support is really interesting, but the JVM dependency is a dealbreaker. Have you considered a full restful API so that client's can be written to talk to the build server?

This way it could be possible for a Visual Studio add-in to be written in .NET that uses the VS SDK to read and understand the developer's solution/code environment, present a better UI perhaps with use cases and wizards, and then it can programme TC via the API. You could even run an innovation competition with cash prizes to get people building.

You see, the faster people succeed and can setup TC, the quicker they'll run into their limit and the faster you'll convert them.

I've noticed that in recent versions you now checkout the codebase and can offer file/folder pickers in the UI. This is exactly the sort of improvement I'm talking about that reduces the iterative, heuristic nature that currently exists, with lots of failures before success. Doing the same with the solution and project files is surely the next step and finally, building a wizard that covers several basic, top use-cases follows that.

Keep in mind that I think you already have a great product and that my feedback is given to help you make it even better.

Luke

0
Comment actions Permalink

Hi Luke,

Thank you for the comments.

As to REST API - it is availalbe and does covers some common tasks. For example it allows to create/edit projects and build configurations with almost all the settings. There are even several wrappers including .NET.

0

Please sign in to leave a comment.