TeamCity
Powerful CI/CD for DevOps-centric teams
TeamCity: Beyond Continuous Integration, Webinar Recording
The recording of our June 26th webinar with Wes McClure, TeamCity: Beyond Continuous Integration, is now available on JetBrains YouTube Channel.
In this webinar, we explore the landscape of opportunities beyond Continuous Integration. See how build chains and dependencies provide a robust framework to orchestrate the benefits automation can bring, to the software you create.
The prior webinar mentioned in the recording is Getting Started with TeamCity. Wes’s slides are available on SlideShare.
Below are select questions and answers from our webinar.
Q: I have my TC 8.1.2 but I cannot find the build chain pane. Where is it?
A: You’ll see build chain tab once you run a build with snapshot dependencies.
Q: If another project A causes a test in Project B to fail, but project A itself is fine, then we will not know what causes the test to fail. Is there a way to change the build number of the test in Project B to reflect that this test was triggered by project A?
A: If project B depends on project A somehow (by snapshot or artifact dependency), you can include build number of project A in build number of project B.
Q: I’m using maven to build my Java application. Can I parse maven project version from the pom.xml and combine with the %build_counter% to form my artefact version?
A: Yes, you can. You can use %maven.project.version% parameter in build number.
Q: You mentioned triggers: Where in this chain would you put your trigger?
A: In this particular example, you should place trigger in Deploy QA configuration.
Q: Why is “pull” triggering better than “push” triggering?
A: In case of “pull” triggering TeamCity has a chance to reuse builds. Say you start Deploy QA and it places all other builds in the queue. Next TeamCity checks to see if there are already finished builds from this chain that can be reused. If there are some, it will take them and will not run new builds.
Q: To tell what is in a build, is that solely in the version control system or does TeamCity provide a view of the changes?
A: TeamCity detects version control changes and shows them in the UI. With snapshot dependencies you can also configure it to show changes from dependencies. So with deploy QA you can always see what changes were included into the build from the deploy QA dependencies.
Q: Are we planning to have any signing feature, e.g. signing the release with approval?
A: You can configure TeamCity to ask for confirmation when some potentially dangerous build is being triggered