Webinar Recording: Using TeamCity 10 to Version Control Your Continuous Delivery Pipeline

Yegor Naumov

A couple of weeks ago, ClearMeasure, our partner, held a webinar titled “Using TeamCity 10 to Version Control Your Continuous Delivery Pipeline“. In this webinar, Jeffrey Palermo (Managing Partner and CEO of Clear Measure) and Yujie Wu (software engineer at Clear Measure) demonstrated the high points of TeamCity 10 and dove into a fully-configured continuous delivery implementation using code-based build configurations.

The webinar focuses on the following points:
– How to convert your existing TeamCity builds into versioned code-based builds
– Demonstration of a fully operable CD pipeline using TeamCity 10 with downloadable code, build config, and everything needed to replicate it on your own

Here is the recording of that webinar, along with the select Q&A from the session:

https://youtu.be/Z6bRO3d7vag

Q:  Why use Build Chains with one step build configurations vs multiple steps in a single build configuration?
A:  There can be a variety of reasons. First, build chain is not necessarily a pipeline, it’s a graph. Build chain allows to run tasks in parallel, if possible. Second, build chain allows to not rerun the build if there were no changes. And actually there are many other reasons as well, such as better visibility into steps and so on. Sometimes multiples steps are better, sometimes build chains are more convenient.

Q:  Would Kotlin-based build configurations replace the concept of TeamCity build configuration templates?
A:  No, templates will remain. DSL is much more flexible, but templates are still handy in many cases.

Q:  So, you would choose one or the other depending on your use case?
A:  Exactly. In case when templates are not enough, you can go with DSL.

Q:  Are the artifact dependencies strictly necessary for the “promote” build configs? I have the same type of build chain setup, but my “promote” build configs only have the snapshot dependency set. Wouldn’t Octopus Deploy restrict what release gets promoted?
A:  Artifact dependency is the way to share build results with other builds. For example, you have built and tested parts separately and on the last step you combine them into a single package.

Subscribe to TeamCity Blog updates

Subscribe form

By submitting this form, I agree to the JetBrains Privacy Policy Notification icon

By submitting this form, I agree that JetBrains s.r.o. ("JetBrains") may use my name, email address, and location data to send me newsletters, including commercial communications, and to process my personal data for this purpose. I agree that JetBrains may process said data using third-party services for this purpose in accordance with the JetBrains Privacy Policy. I understand that I can revoke this consent at any time in my profile. In addition, an unsubscribe link is included in each email.

Submit

Thanks, we've got you!