Search code examples
asp.netgitdeploymentteamcityspringloops

How to merge and commit to a branch in TeamCity

I want to figure out how to integrate TeamCity builds with Springloops deployments.

Lets say I have a Git repo called api that has two branches dev and dev.build

api
|-- dev
|-- dev.build

I have set up TeamCity with a VCS trigger on dev to build upon commit. Which then creates artifacts that I want to use to deploy. (In this case it's an ASP.NET website with various DLLs that I want to use for deployment).

I also have Springloops that I use right now for deployments. Ideally I would like to deploy from dev.build. Is there a way to commit build artifacts from TeamCity to the dev.build branch, and then deploy from that branch?

The basic workflow would be

  1. Commit code to dev
  2. TeamCity merges dev into dev.build
  3. TeamCity builds from dev.build
  4. TeamCity commits artifacts (DLLs) to dev.build
  5. Springloops auto deploys from dev.build

I have read arguments against storing build binaries/artifacts in git, but right now I do my deployments from Springloops, and ideally I could keep that setup. I know you can call git as a command line build step, but I'm having trouble putting all the pieces together. Especially how to merge from dev to dev.build as a TeamCity build step and then use dev.build to build from.

Is this possible at all? Am I thinking about this completely wrong? Do I have other options?

Edit/Update

I've found that it will be smarter to switch to using WebDeploy to deploy TeamCity artifacts (WebDeploy package) instead of committing build artifacts from a git repository via Springloops. I will hopefully stop using Springloops for deployments and deploy directly to my IIS sites via WebDeploy through a TeamCity build task. This way build artifacts (\bin folder) will stay out of git, and web.config transforms can also be used instead of manually making web.config edits on production IIS sites.

Solution

  • The other option I would recommend is to build a TeamCity Artifact, which is there to store the result of your job in an integrated lightweight builds artifact repository.

    That way, Springloops could look for artifacts to deploy directly on a TeamCity url (or on a TeamCity agent).
    That would scale better than trying to put those artifacts in a source code repo like Git, which isn't made for that.

    Regarding the TeamCity build itself, it could be compose of two jobs (one dependent on the other) with the first one using the automatic merge feature, in order to merge dev to dev.build.