1

Lets assume for a moment you have a project with 20+ VCS entries consisting of SVN and GIT repositories. Each has been configured and connectivity works.

The same project consists of numerous build configurations with artifact and snapshot dependencies. For example, there may be one for building the source from all the VCS repositories and upon success, create a tag/label in each repo with the build number. Another configuration, dependent upon the artifacts produced by the build, may deploy the binaries to one or more staging servers, and yet another may run automated acceptance tests against the deployed system. This process may repeat for testing performance, security and so forth.

Finally when all the build configurations completed, there is one to create a release branch (e.g. release-1.2.3) in each VCS repository. This is usually triggered manually once a release cycle.

enter image description here

Currently I'm running a script to create the branch in each repository and if needed (as with Git) push it to the origin server. The problem is that I have to maintain the list of repositories in several locations and this is rather error prone, especially when it comes to security.

In essence, I'd like to do something similar as the VCS Labeller, except that I'd like to create a branch in each VCS repo.

Short from having to write a custom plugin, how does one use the VCS information to create and push a branch to each repo?

Krzysztof Wolny
  • 10,576
  • 4
  • 34
  • 46
bloudraak
  • 5,902
  • 5
  • 37
  • 52
  • Can you describe how you'd like to have this process setup? Should all be automated or you allow to some manual actions? When this branches should be created? Having some example would be helpful. – Krzysztof Wolny Jun 16 '15 at 18:50
  • Can you explain why you have different VCS systems? Why not just git? Why not just one repository? – Lasse V. Karlsen Jun 16 '15 at 19:40
  • 1
    Why different VCS systems? Most systems I worked on are older than a decade. Some were around before SVN became the kool-aid folks drank,never mind git. The cost (monetary, time, resources) of migrating a legacy codebase simply isn't worth the benefit. As components are rewritten, they are migrated to new repos. Having small segregated repos and sharing binaries with a package manager is the latest trend. Changing this isn't really up for discussion. – bloudraak Jun 17 '15 at 07:10
  • The only manual step is for QA to promote the build to a release using the TeamCity UX. The rest is fully automated using scripts. The challenge is that the scripts get out of sync with the TeamCity build configuration; hence the question. – bloudraak Jun 17 '15 at 07:13

0 Answers0