Poll: TeamCity web UI

1. How many projects and configurations for each project do you have on
your projects dashboard?

1 production project (6 build configs), 1 sandbox project (variable
number of builds)

2. How often do they have overlapping VCS roots?

Always

3. Where do you usually go from the dashboard:
a) build results
b) build configuration homepage
c) usually I obtain all necessary information in the pop-up windows right on the dashboard

d) Build results history since we often don't address build failures as
soon as they occur and I need to find out when a build first started failing

4. What is your main complain about TeamCity dashboard?
a) it shows too much, I'd like less (why)
b) it doesn't show the information I need (which?)

It's about right for me, although I would like to see the agent name
without having to look at a tooltip, and since we have agents in
multiple time zones it would be nice if the dashboard showed times in my
time zone instead of the agent's.

5. Would you like to see any particular stats information right on the dashboard (having in mind that the separate Project health stats page will be available)

See above.

One final comment - TeamCity handles the "normal" case (lots of unit
tests that never fail) very well. However, we have some functional
tests that can fail repeatedly over a long period of time and this isn't
well handled (e.g. code change validly changes test results and it takes
some time to regenerate a baseline). I've already made the case for
cutting down on the number of duplicate e-mails, but being able to
assign per-test failure responsibility would help us greatly as well.

Thanks and hope that helps,
R

1. How many projects and configurations for each
project do you have on your projects dashboard?

24 projects
31 build configs

The # of projects would reduce depending on the fix for TW-792.

2. How often do they have overlapping VCS roots?

Rarely.

3. Where do you usually go from the dashboard:
a) build results

Usually to view build logs.

4. What is your main complain about TeamCity dashboard?

b) it doesn't show the information I need (which?)

There's a lot of blank space that could be used to give information.
- e.g: When a build is running it says: "Running 1 build".
How about "Running build on agent " instead. - Add "Build started by " and if it was stopped by a user have: "Build terminated by ]]>" instead.
- See TW-1437.

5. Would you like to see any particular stats
information right on the dashboard (having in mind
that the separate Project health stats page will be
available)

Not really. I will say that many of our users find that there is too much
information on the Projects page while I find there to be too little. Perhaps
one way to handle this is to keep the projects page and add a configurable
dashboard page that becomes the overview page. The new page could add
user-specific content like builds that have changes of the user and perhaps
a simple graph of # of builds broken by the user.

-Dave

1. How many projects and configurations for each
project do you have on
your projects dashboard?

1 project, 6 configurations

2. How often do they have overlapping VCS roots?

Never

3. Where do you usually go from the dashboard:
a) build results
b) build configuration homepage
c) usually I obtain all necessary information
in the pop-up windows right on the dashboard

Build results

4. What is your main complain about TeamCity
dashboard?
a) it shows too much, I'd like less (why)
b) it doesn't show the information I need (which?)

Some indication of how a build was triggered (manual, timed, checkin, dependent) would be handy. I might like to be able to see a count of files changed directly, rather than by clicking through the changes, but that's less important.

5. Would you like to see any particular stats
information right on the dashboard (having in mind
that the separate Project health stats page will be
available)

Just the file count, described above.

--Dave Griffith

2 projects with 2 configurations each, which have the same VCS roots. There's also 1 "utility" project that doesn't do a build as such, but is used to restart IIS on our test web servers with a single click.

From the dashboard I usually want to go to build results. However, there are times when the build has failed and build results only show "failed", but not the cause of the failure, eg. when MSBuild throws an exception. I already knew that it failed from the dashboard, so I then have to click on "Build Log" to find out the real problem. It would be nice to see the erro on "Build Results".

The one piece of info I keep looking for on the dashboard is which build agent a build is running on.

1. Right now, 10 projects totalling 17 build configurations --- and growing. We have plenty of projects to be added.

2. Pretty much always. We have shared library directories and shared code, referenced by multiple projects.

3. About half the time I go a) to the build results (typically I hover over the arrow to get the direct link to "important messages" and shift-click that to open in a new tab in Firefox), and the other half of the time I go b) to the build configuration homepage, typically to look at the build history and find the first failure and the changes associated with that.

4. b), things to add:
- for each failing build configuration, how many consecutive builds have failed, and when the first one failed.
- for each ongoing build, which agent it is running on.
- for each build configuration that is in the queue, a link to remove it from the queue (at least for build configurations that are in the queue but have no pending changes).

5. Average build time of each build configuration (perhaps a moving average of the last ten builds or so) would be nice to have, to see whether the current build is taking abnormally long.

1. How many projects and configurations for each
project do you have on
your projects dashboard?

3 projects, 4 total configurations. One project has a nightly code coverage enabled build in addition to the main build.

2. How often do they have overlapping VCS roots?

Always. These are not logically 3 different projects, but are 3 different branches of the same project.

3. Where do you usually go from the dashboard:
a) build results
b) build configuration homepage
c) usually I obtain all necessary information
in the pop-up windows right on the dashboard

A. Mainly interested in test failures.

4. What is your main complain about TeamCity
dashboard?
a) it shows too much, I'd like less (why)
b) it doesn't show the information I need (which?)

B. There is no support for relating different branches (production, test, development/head) of what is essentially a single project.

5. Would you like to see any particular stats
information right on the dashboard (having in mind
that the separate Project health stats page will be
available)

A. The project description could usefully be added to the dashboard as this is entered as a one-liner in the project config.
B. Some VCS branch info would be nice.


Kind regards,

Maarten

1. How many projects and configurations for each
project do you have on
your projects dashboard?

250 projects. 2 configurations each.

2. How often do they have overlapping VCS roots?

Always.

3. Where do you usually go from the dashboard:
a) build results
b) build configuration homepage
c) usually I obtain all necessary information
in the pop-up windows right on the dashboard

Build Configuration Homepage

4. What is your main complain about TeamCity
dashboard?
a) it shows too much, I'd like less (why)
b) it doesn't show the information I need (which?)

I would like to see a project/config search feature on the dashboard. The type whereby you would see projects/config be filtered as you type.

Currently have 6 builds for a total of 12 build configs.

Having just spent a bunch of time setting up new builds, I would find it helpful to have an "edit config" button for each config on the dashboard page when logged in as an admin. I seem to spend a lot of time scrolling to the build I'm interested in, discovering I need to edit the config, then clicking the admin button, and then have to search for the project again in the new list, which is in a different order. At minimum having the build config listing page respect the user's project ordering.

I'd like to always have a link to the most probable item of interest for a build, as an alternative to the current artifacts link. For a regular, successful build, this would be the artifacts link. In the case of a failed build, it would be to the build log - important messages page. In the case of an inspection or duplicates build, it would be to the corresponding result page.

Minor cosmetic detail: when checking out, the "checking out" status line wraps to two lines if the file name is really long. This leads to somewhat disconcerting jumpiness in the display as the file name alternates between long and short. Perhaps don't re-shrink the space once it has been grown?

Would be nice to have a link to the dashboard page that did not require a login of any kind (ie automatically assume guest if not already logged in). Would be extra nice if the expanded/collapsed state could be encoded in the URL as well (use case: we have a need to have a quick overview of build status available to lots of people, and would rather not have to explain the login process to someone who only needs to see the status and otherwise has no interest in the build process)
To further improve this benefit, the collapsed view seems to have some extra space that could be used to display some of the info normally only available in expanded mode. The last build id, and a link to the artifacts (or inspection/dup report, see above comment)

1. How many projects and configurations for each
project do you have on
your projects dashboard?

250 projects. 2 configurations each.

2. How often do they have overlapping VCS roots?

Always.

This information makes me really curious. May I ask you, what kind of projects do you have? Why they always have overlapping VCS roots?

With kind regards,
KIR

Having just spent a bunch of time setting up new
builds, I would find it helpful to have an "edit
config" button for each config on the dashboard page
when logged in as an admin. I seem to spend a lot of

Agreed, good point. Probably, we'll add "quick links" menu near build configuration
name to provide more navigation possibilities.

time scrolling to the build I'm interested in,
discovering I need to edit the config, then clicking
the admin button, and then have to search for the
project again in the new list, which is in a
different order.

For now, you can simply visit build configuration page and
find "Edit build configuration" link in the popup menu
(or right on the page if you use latest EAP)

At minimum having the build config

listing page respect the user's project ordering.

Please watch/vote for http://www.jetbrains.net/jira/browse/TW-2620

I'd like to always have a link to the most probable
item of interest for a build, as an alternative to
the current artifacts link. For a regular, successful
build, this would be the artifacts link. In the case
of a failed build, it would be to the build log -
important messages page. In the case of an inspection
or duplicates build, it would be to the corresponding
result page.

I'd suggest that build results page should show different information
depending on build configuration type and build status. Like
http://www.jetbrains.net/jira/browse/TW-1569
What do you think?

Minor cosmetic detail: when checking out, the
"checking out" status line wraps to two lines if the
file name is really long. This leads to somewhat
disconcerting jumpiness in the display as the file
name alternates between long and short. Perhaps don't
re-shrink the space once it has been grown?

Could you please file an issue with screenshot?

Would be nice to have a link to the dashboard page
that did not require a login of any kind (ie
automatically assume guest if not already logged in).

http://buildserver/overview.html?guest=1

Would be extra nice if the expanded/collapsed state
could be encoded in the URL as well (use case: we
have a need to have a quick overview of build status
available to lots of people, and would rather not
have to explain the login process to someone who only
needs to see the status and otherwise has no interest
in the build process)
To further improve this benefit, the collapsed view
seems to have some extra space that could be used to
display some of the info normally only available in
expanded mode. The last build id, and a link to the
artifacts (or inspection/dup report, see above
comment)

Do you know that there is a possibility to embed build status
to external web site? Please read about this at
http://www.jetbrains.net/confluence/display/TCD/CreateEditBuild+Configuration
(search for 'Enable status widget' line).
I suppose it may solve your problem.

Kind regards,
KIR

Hello everyone,

I'd like to thank you all for your time and for your efforts answering the poll and
sharing your ideas. We'll try hard to improve TeamCity UI and to take into account
your opinion.

Thanks again,
KIR

Minor cosmetic detail: when checking out, the
"checking out" status line wraps to two lines if

the

file name is really long. This leads to somewhat
disconcerting jumpiness in the display as the file
name alternates between long and short. Perhaps

don't

re-shrink the space once it has been grown?

Could you please file an issue with screenshot?

I just happened to see it on my system, so I snapped some shots and created
http://www.jetbrains.net/jira/browse/TW-2625

Kind regards,

Maarten

1. How many projects and configurations for each
project do you have on
your projects dashboard?

250 projects. 2 configurations each.

2. How often do they have overlapping VCS roots?

Always.

This information makes me really curious. May I ask
you, what kind of projects do you have? Why they
always have overlapping VCS roots?

With kind regards,
KIR

Sorry. Maybe I misunderstood the original question...I have common VCS roots...not overlapping.

All my projects share a VCS root in SVN where we keep common scripts.

As for my projects, they are ANT based which build C++ projects.

Thanks,

Scott