{"id":474955,"date":"2024-05-21T11:22:42","date_gmt":"2024-05-21T10:22:42","guid":{"rendered":"https:\/\/blog.jetbrains.com\/?post_type=teamcity&p=474955"},"modified":"2024-07-02T17:53:08","modified_gmt":"2024-07-02T16:53:08","slug":"deploying-to-multiple-targets","status":"publish","type":"teamcity","link":"https:\/\/blog.jetbrains.com\/zh-hans\/teamcity\/2024\/05\/deploying-to-multiple-targets","title":{"rendered":"Deploying to Multiple Targets With Ease"},"content":{"rendered":"\n

Have you ever been faced with a situation where you needed to deploy your system to many different environments? For many of us, this is probably just staging or production. When using TeamCity to do this, we just create a build chain as follows:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

But what if the number of deployment targets is higher, like ten or more? <\/p>\n\n\n\n

In this case, we might end up with a build chain ending with a set of Publish to env*<\/em> deployment build configurations:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

In such cases, it\u2019s always better to have a combining build configuration that has dependencies on all the Publish<\/em> tasks:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Unfortunately, due to the current limitations of TeamCity, this combined Publish<\/em> build configuration can\u2019t be both composite<\/a> and deployment at the same time. We\u2019ve already had this feature requested<\/a> by some users. <\/p>\n\n\n\n

In this case, the build won\u2019t be shown as running if any of the Publish to env*<\/em> dependencies are still running, which is a bit inconvenient.<\/p>\n\n\n\n

Maintaining the configuration<\/h2>\n\n\n\n

If we\u2019re using the Kotlin DSL, we can program such a build chain relatively easily, as we can just create a loop that will generate all these Publish to env*<\/em> build configurations. You can see an example of similar Kotlin DSL code in one of our previous posts<\/a>.<\/p>\n\n\n\n

If we\u2019re not using the Kotlin DSL, then we have to create the build configurations via the UI. Usually, in such cases, creating a template<\/a> first would be quite helpful. Maintaining this type of deployment configuration is much simpler with templates. However, even with a template, it still takes a lot of clicks to change anything in the configuration.<\/p>\n\n\n\n

Moreover, whenever we add a new environment, we still need to create a new build configuration and add a dependency to it from the Publish<\/em> build configuration. <\/p>\n\n\n\n

All of this feels cumbersome, especially if the number of deployment targets is quite large. Is there really no better way?<\/p>\n\n\n\n

Using Matrix builds<\/h2>\n\n\n\n

If we\u2019ve already defined a template for the actual Publish to env*<\/em> build configurations, then we\u2019ve already generalized our publishing scripts such that they now accept a parameter denoting a particular environment and perform publishing based on that. In this case, a much better approach would be to use the Matrix Build feature<\/a>.<\/p>\n\n\n\n

To do this, we can add a Matrix Build feature to the Publish<\/em> build configuration with a matrix parameter with the desired name and an array of values:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

The Publish <\/em>build configuration won\u2019t need dependencies on Publish to env* <\/em>build configurations anymore. Instead, it will have a dependency on Test<\/em>. The deployment steps will be copied from a Publish to env*<\/em> template. <\/p>\n\n\n\n

In regards to the configuration of the dependencies, the resulting build chain will look the same as in the beginning:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

However, if we trigger a Publish build configuration, its build will be transformed into a composite build with automatically generated dependencies on a set of parallel [env*]<\/em> tasks, one for each value of the matrix parameter:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

If you look closer at this screenshot, you can see that the Publish<\/em> build is shown as running even though its dependencies are not finished yet. So, apparently a build can<\/em> be both composite and deployment at the same time. This looks like a nice solution, at least for some of the users who voted for the composite deployment build feature<\/a> ticket.<\/p>\n\n\n\n

With the Matrix Build feature, the settings become much simpler. Now, there\u2019s no need to have a template or a dedicated build configuration for each environment. <\/p>\n\n\n\n

At the same time, adding a new environment is as simple as adding a new value to the matrix parameter (provided that our scripts understand this value). <\/p>\n\n\n\n

The presentation of the results looks nicer too:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Matrix Builds also allow us to retain flexibility. For instance, if an [env*]<\/em> build fails, we can retry this individual build or better yet, we can rerun the Publish<\/em> build itself with the Rebuild failed dependencies<\/em> option:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

If our publish build requires an artifact prepared by the Build package<\/em> task, we can just add an artifact dependency to the Publish<\/em> build itself. When it is executed, the same dependency will be copied to the auto-generated [env*]<\/em> builds so they all use the same artifact.<\/p>\n\n\n\n

Finally, these [env*]<\/em> build configurations won\u2019t clutter our view as they won\u2019t be visible by default. If necessary, one can always navigate to them and analyze their history.<\/p>\n\n\n\n

Once again, the Matrix Build feature<\/a> proves to be quite useful. If you\u2019re using TeamCity 2023.11+, please give it a try and tell us how it can be improved!<\/p>\n","protected":false},"author":136,"featured_media":475064,"comment_status":"closed","ping_status":"closed","template":"","categories":[808],"tags":[83],"cross-post-tag":[],"acf":[],"_links":{"self":[{"href":"https:\/\/blog.jetbrains.com\/zh-hans\/wp-json\/wp\/v2\/teamcity\/474955"}],"collection":[{"href":"https:\/\/blog.jetbrains.com\/zh-hans\/wp-json\/wp\/v2\/teamcity"}],"about":[{"href":"https:\/\/blog.jetbrains.com\/zh-hans\/wp-json\/wp\/v2\/types\/teamcity"}],"author":[{"embeddable":true,"href":"https:\/\/blog.jetbrains.com\/zh-hans\/wp-json\/wp\/v2\/users\/136"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.jetbrains.com\/zh-hans\/wp-json\/wp\/v2\/comments?post=474955"}],"version-history":[{"count":8,"href":"https:\/\/blog.jetbrains.com\/zh-hans\/wp-json\/wp\/v2\/teamcity\/474955\/revisions"}],"predecessor-version":[{"id":490021,"href":"https:\/\/blog.jetbrains.com\/zh-hans\/wp-json\/wp\/v2\/teamcity\/474955\/revisions\/490021"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.jetbrains.com\/zh-hans\/wp-json\/wp\/v2\/media\/475064"}],"wp:attachment":[{"href":"https:\/\/blog.jetbrains.com\/zh-hans\/wp-json\/wp\/v2\/media?parent=474955"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.jetbrains.com\/zh-hans\/wp-json\/wp\/v2\/categories?post=474955"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.jetbrains.com\/zh-hans\/wp-json\/wp\/v2\/tags?post=474955"},{"taxonomy":"cross-post-tag","embeddable":true,"href":"https:\/\/blog.jetbrains.com\/zh-hans\/wp-json\/wp\/v2\/cross-post-tag?post=474955"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}