CODEWITHSUNDEEP
.netgitdeploymentteamcityoctopus-deploy
Manny42
Manny42

Reputation: 648

Deploy .Net Website from three different branches

I am not sure if I should ask this here or on ServerFault but I am trying to put together a way of making production patches easier when we find a problem. We have several websites in one git depo, right now what we do is use a TeamCity server to build the .nupkg for each website, then we push it to octopus that handles the publishing to the dev, UAT and production servers.

I have been trying to make TeamCity build from a different branch and push the built package to octopus but that means the we'll need 3 projects per website for each TeamCity and Octopus to handle this kind of architecture.

I would like to know if there is a better way to handle what I want to achieve.

UPDATE: Maybe this needs a little more explanation. We have one repo, for all the websites. As bad as this is this is, this is how it is right now and we can't really change it now. But I wanted some insights from people using .Net and a Dev/UAT/master branching strategy for their deployments.

Upvotes: 0

Views: 46

Answers (1)

Ben Richards
Ben Richards

Reputation: 3575

There is always a better way but what you are asking takes some work. Here is how I am handling a similar scenario. In my case I have a single application all under a single Git repository, but I want the application deployed to a different web site based on the Git branch. So here is how I've set this up:

Prerequisites:

PowerShell

PSake - A PowerHhell build framework for .NET applications

  1. I have a Psake build file that resides in each branch, it can be run locally from the command line, but it's also used by TeamCity to run the build. That build file takes a name of a branch as a parameter, builds and packages the solution by using the name of the branch to create the package ID for the NuGet package. For example, if my branch is called "feat-API", i strip the "feat-" and my NuGet package ID becomes "api.myapp.com" and when the NuGet package gets built, it becomes "api.myapp.com-2017.05.26.nupkg"
  2. Once the package is built, it's pushed to the NuGet feed on the OctopusDeploy server but without actually triggering a release.
  3. The next step is the PSake build script calls the Octopus API and triggers a new release, passing the ID of the package as a parameter.
  4. On the Octopus Deploy end, I have a single project, with a custom step template that takes a parameter...you should have guessed it by now, the package ID.
  5. To actually make this generic enough to work, your package needs to contain the actual deployment. I am using Chocolatey (an enhanced version of NuGet of sources) and since NuGet/Chocolatey are just PowerShell based, the install script inside the package handles the actual deployment. It takes as parameters the Octopus Environment in which it's running, constructs the values it needs to do the deployment from a config file and an environment specific file, and deploys the web site, etc.

As you can see, it's doable, but not simple.

Upvotes: 1

Related Questions