10 comments

Hello Bonny,

Could you please explain this in a bit more detail?

What are you trying to achieve and what features can help you with this?
Could you describe a sample workflow for the feature?

--
Best regards,

Yegor Yarko
Quality Assurance Engineer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

0

If I should take a guess at it, he wants to go from the artifact to the list of JIRA issues solved in that build.

As far as I have understood, TeamCity can link to JIRA (or other web based issue trackers) through having checkin comments on a specific format, for example SPRING-23. You then setup a comment transformation in TC's main-config.xml that will exchange SPRING-23 into the link to this issue in your JIRA server.

For a more thorough explanation, see http://www.jetbrains.net/confluence/display/TCD3/MappingExternalLinksinComments.

So to get "build --> JIRA issues" functionality, I think you must make a plugin. Is this feasible with the current API?


Regards,
Stig Kleppe-Jørgensen

0

Stig

Thanks for the suggestion. This is mostly what I'm after and I've set it up to perform
as documented.
However, I guess my question has a larger scope (at least in my mind): How do I tie
up changes related to an issue with that issue's resolution. For example (and this may
be trivial to you, so bear with me here):
1. A build is done and goes to testing. An issue is found and created in, say, JIRA.
2. Developers are working on the fix and marking checkin with the issue number. At this point, should the issue be marked as resolved, but still open? or is it up to the testing team to mark this issue as resolved?
3. A new build incorporating these changes is performed and is being tested. The issues are indeed fixed. How can I (automatically, if possible), close the issues in a manner that is clearly related to the build?

Also, another question: is the common practice to tag the repository for a project with a
build number with every build? (Is there an issue with CVS managing a large number of
tags for files even w/o change?)

Cheers,

Bonny

0

Stig,

Thank you for the comment.

There is room for improvement in integration TeamCity and issue trackers. I guess most of the functionality can indeed be implemented as a plugin.

e.g. one case which I believe can be implemented with the current TeamCity open API can include adding new tab to the build results page with a list of links to issues that are referenced in the comments of the build's changes.

--
Best regards,

Yegor Yarko
Quality Assurance Engineer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

0

Bonny,

Thank you for elaborating on the issue.

We speculated internally on the feature to automatically resolve issues specially referenced in commits comments. You can comment/vote for the feature filed as http://www.jetbrains.net/jira/browse/TW-2304

What should occur with the issue on commit and then on successful build depends largely on the workflow used. In the default Jira workflow I'd assume that issue should be resolved as "Fixed" on successful build. Usually the testing team will then test and "close" the issue manually afterwards. Upon automatic fix TeamCity can leave comment with the "fixed in" build number or fill some custom Jira field with the build number.

I guess that each issue should be closed/fix confirmed individually because issues are usually tested individually.

Summarizing, there is no such level of integration in TeamCity currently, but much of the discussed functionality can be implemented via a plugin to TeamCity.

--
Best regards,

Yegor Yarko
Quality Assurance Engineer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

0

Bonny,

Also, another question: is the common practice to tag the repository for a project with a
build number with every build? (Is there an issue with CVS managing a large number of tags for files even w/o change?)


How lots of tags affect performance/storage space is indeed version control specific.

We do have a request for the feature in Jira: http://www.jetbrains.net/jira/browse/TW-20

--
Best regards,

Yegor Yarko
Quality Assurance Engineer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

0

Yegor,

Could you shed some light on the way this is done in JB? You guys have obviously
got the scenario I've described before (more or less, I suppose) impemented, and
rather than reinvent the wheel, some description of JB's practice might go a long
way towards making better use of TC.

Do you guys tag every build? How else do you indicate a particular build (other
than the artifacts of course) in the VCS in case you needed to recreate it?
Have you got some indication of the difference in performance in this regard between
the different VCS implementations?

Cheers,

Bonny

0

Bonny,

Thank you for elaborating on the issue.

We speculated internally on the feature to
automatically resolve issues specially referenced in
commits comments. You can comment/vote for the
feature filed as
http://www.jetbrains.net/jira/browse/TW-2304

What should occur with the issue on commit and then
on successful build depends largely on the workflow
used. In the default Jira workflow I'd assume that
issue should be resolved as "Fixed" on successful


Is this done as a result of using a convention where by a successful
build includes (for a change set) a set of automatic tests that
are tied to the logged issues? Can this be extended in TC to involve
something of a workflow whereby the build is actually tested by
a QA engineer (for tests that cannot simply be done using unit/mock
tests) and if the issues are indeed fixed, then TC can perform the
resolution and in the case of failed tests, TC can push the issues
back to the developers?

build. Usually the testing team will then test and
"close" the issue manually afterwards. Upon automatic
fix TeamCity can leave comment with the "fixed in"
build number or fill some custom Jira field with the
build number.

I guess that each issue should be closed/fix
confirmed individually because issues are usually
tested individually.

Summarizing, there is no such level of integration in
TeamCity currently, but much of the discussed
functionality can be implemented via a plugin to
TeamCity.


Is there a sample server side plug-in documenting the TC build life cycle?

Cheers,

Bonny

0

Bonny,

Extensive TeamCity-issue tracker integration is yet to come and I hope there will be moves in the direction in the future versions. But we do not have any specific development plans for the integration yet.

I am not sure TeamCity can help much with issue workflow other then automatic issue resolving based on the changes comments. For the companies that have their issue tracker as single point of attention issues can be automatically created on build/test failure, but this does not seem to be common practice and thus is more suitable to be implemented as not-core plugin.

IMHO, issues that are tested manually should be manually reopened/commented/assigned and the issue tracker seems the most suitable place to do this.

Is there a sample server side plug-in documenting the TC build life cycle?


I am afraid there is not for the time being. We do plan to provide TeamCity openAPI documentation and sample plugins to make writing new plugins easier. For the time being you can refer to short plugin basics description at
http://www.jetbrains.net/confluence/display/TW/Plugin+Development
and post questions for us to answer.


--
Best regards,

Yegor Yarko
Quality Assurance Engineer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

0

Bonny,

We still have a lot we would love to do when we are done with more priority tasks :) As it turns out, some of these "not just now" tasks are about TeamCity-tracker integration...

So our workflow still can be automated/improved a lot.

Usually, developers resolve issues as soon as the change is committed. Change comment can have reference to the issue it fixes. When distribution build succeeds (we have those to run once a day but also start them manually during the day if needed), tester would grab the distribution and test the recently closed issues. If in doubt, changes comments can be consulted whether the fix got into the build.

Then, based on the results of manual testing issues can be closed or reopened with appropriate comments.

As to VCS tagging, to say the truth, I could not recall the time we wanted to recreate a build. We store all the builds released to public (pining them in TeamCity to prevent builds from cleaning up) and this are the builds we need usually. We do not tag VCS for builds. In fact, if we have the build in TeamCity we have it's timestamp and could get the sources for the timestamp from the VCS. If needed, full sources copy (packed of course) can be stored as build artifact together with scrambler logs, etc. So, usually all we need can be found in build artifacts.

--
Best regards,

Yegor Yarko
Quality Assurance Engineer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

0

Please sign in to leave a comment.