Scaling TeamCity Overview page for many projects
I'd like to start a separate discussion on the issue "no spamnerd" brought up in the 6.0 wishlist topic.
In brief, the issue is that TeamCity Overview page does not serve its "overview" purpose well when the TeamCity installation grows large and has many projects, each with own branches, etc.
Possible approaches to the issue can vary from as complex as portlet-like widget solution which is customizable per-user to as simple as ability to tag build configurations + easily switch the view to display only specifically tagged ones.
Related ideas from the tracker:
TW-705 - Allow projects to be grouped into categories and viewed/managed by these groupings
TW-11124 - Grid view for projects list page to fit more on the page without needing to scroll
Could you describe what do you want from the Overview/"Home" TeamCity page mentioning the root needs that you have? If you have ideas on implementation, please share them but do not forget to describe what pains you need to relieve or what insight to get with the solution.
Please sign in to leave a comment.
Yegor,
I think http://youtrack.jetbrains.net/issue/TW-705 is a good start and their are a lot of good points in the suggestions. I still am sticking by my suggestions to give us some tree like structure to group and order things better.
In addition to those, let me try to explain more of what we are going through with our migration into TC.
For us, we have broken up our big build processes into smaller configurations to take advantage of a lot of what TeamCity has to offer. For instance, our old build was a single process from source operations to compilation to the final publishing step. After the publish step, we would run some regression testing and QA testing. These are all separate operations, with most being automated and some manual. The build process would update the status on a webpage, the regressions use a custom interface to display test results, and QA uses spread sheets, bug tracking, and html reports. The beauty with TC is that all those steps are visible in one place! This is good but not everybody cares about following all the steps.
So, to simplify things, our build process was broken up into a core build configuration and a publish step. We created a deployment/installation configuration and a regression run, along with some code analysis steps. For build engineers, we may like to see the results of all these along with the details. For developers, they may only care about the build status and maybe the analysis steps. For an test engineer, they may only care about the results from the regressions. Product management wants to see the big picture.
So lets focus on just one project that may have twenty configurations for multiple platforms. How does someone other than a build engineer look at that particular project and get an idea of what the status is at that moment? Even for less configurations it is hard to figure out what is going on.
And maybe this goes back to my lifecyle suggestion, but it would be nice to look at all the builds that occurred for some period and see a high level view of what happened or what is scheduled to happen. For instance, I can look at some chart or graph of all the builds. Say, you focus in on build #6 is tagged as an official daily build. You could see the major part of that build process, from the build, to the deployment, and testing. At each step you could see the status and any tags applied. You could dig down into the details if you wanted, so for instance, maybe the build step was made of twenty or so configurations. Maybe once it passes the regression test step is tagged by QA and deployed for consumption by developers and testers. I could than see where that build was deployed to so that I could consume it. As a developer or tester, I don't want to have to follow twenty different configurations and check the build number, time stamp, and tag to figure out what is going on. Maybe this is something that TC can do today but it isn't yet obvious to me how to do that.
When I have 100 configurations and 20 projects, how do I explain to a product manager what is going on? A full product may span of multiple projects, configurations, and steps. It just isn't easy to get that high level of detail. I guess I want to see a pipeline of a build at that high level and to be able to dig in and see the details if needed. I want to easily be able to see all of the artifacts produced by that whole process from end-to-end.
I (quickly) sketched up a simple mock-up of what I envision so it may be more clear.
The panel on the left, would be the tree or groupings. To the right of the tree, when a product is selected you could see a list of the current builds or some history list as you see in TeamCity today. You may be able to refine this view to the day/week/month... Clicking on that you would see a graph/image/chart of the high level build pipeline. You could see high level details such as build date, build number, tags, pins, build comments. The blocks would be color coded based on the build status so you could see exactly what step a build failed on for instance.
Clicking on one of those blocks would give you a more detailed chart of the individual steps. I grouped this build together to include multiple platforms. Again, the blocks are color-coded for easy identification where the build failed or even where it is currently running. Clicking on those blocks would show you the build log or output for that particular step along with any other information needed such as artifacts produced, just as the details for a build configuration are displayed today in TeamCity are displayed when you click on a build. Maybe the user preferences only care about the build details, so a preference could be set to not show the build pipeline.
Hope this is helpful is someway.
Attachment(s):
BuildUI -.jpg
Please improve the overview page performance. It is ridiculously slow to load. I created a simple page that lists the project/build configuration names so I wouldn't have to wait for the overview page to list the 100+ projects and 500+ build configurations. It's much, much faster.
For what it's worth, we are in a similar bind. The Project overview page is not very useful, and just finding builds becomes really hard. We also ended up writing a separate tool that will generate overview pages that map to our usage.
Same for our organization. A tree structure of some sort would be welcome.
Just a note, we improved Overview page performance in TeamCity 6.5. For example, the content of collapsed projects is not loaded until you expand the project. Although we understand that this is still a workaround, and are looking for better solution.
Load time for the project overview page is enormously better in 6.5.
Hrm we just upgraded from 6.0.3 to 6.5 and now each build configuration on Overview page take up 5 "rows" each (including build number, line separator etc.) :/
Can one somehow change this to be less verbose as it was in 6.0 ? (i.e. like this version where each configuration is only 2 "rows" )
*Edit I now noticed I can "Collapse All" and then "Expand all" to get 1 "line" for each project (unfortunatly this hides our custom generated build/version number) but that was at least an easy option to use :).
*Edit2: Adding attachment in post for http://youtrack.jetbrains.net/issue/TW-17280
Seems like you are interested in TW-17280. Please leave a comment there and watch the issue.