0

I'm planning to develop a multi-tier .NET application, with at least three separate layers hosted on Azure:

  • Web frontend
  • Backend / worker role
  • Database

I would like to use Azure Git Publishing with GitHub to enable continuous deployment of each of the layers separately. What's the best way to organize the git branch(es) to enable Azure deployments for each of the components individually, while also sharing code between them?

Preferably, I would like to have all the code in one git branch and set up separate build/publish processes for each in Azure. However, I suspect this won't work because:

  1. Azure uses any push in a branch to trigger a deployment. I don't want updates to my frontend to trigger a deployment of my backend.
  2. As far as I know, there's no way to configure the build command that Azure uses to generate outputs to publish.

If I need to use separate Git branches, what's the easiest way to share code between them?

Scott Wegner
  • 7,263
  • 2
  • 39
  • 55

2 Answers2

2

Kind sir,

It sounds like you'll need a git repo for each deployment target. That is, a repo for each layer that wishes to be deployed independently of any other. Plus one more repo for the shared code. Presumably the shared code compiles to some dlls, which can be shared with the other projects by bundling them up as a NuGet package. This way the web front end, for example, does not trigger a deployment at the whim of updates to the shared code. That only happens if you've done a NuGet update.

That said, I wonder, is the "don't want updates to frontend to trigger a deployment of my backend" truly a requirement? At my workplace we have nearly all our deployments fully automated. There is no downtime, it just works. We deploy sometimes 5, 10, or more times a day. We don't have to care how many times. If you can do that too, then you can have one big git repo. Yes, occasionally changes that don't affect a layer will still deploy that layer, but meh, don't care. Code organization and sharing become very simple.

Your pal, Josh

Josh Buedel
  • 1,853
  • 16
  • 41
  • Thanks for the response. I see your point not to worry about extraneous deployments, but I would also like the logic separation of deployment targets. At the same time, publishing NuGet packages or similar seems like overkill, I've head git submodules might be the answer I'm looking for. – Scott Wegner Jan 18 '13 at 17:03
0

According to this related question, Azure git publishing is only available for websites, not cloud services.

So, the question of organization to allow for separate project publishing is irrelevant. The easiest option will be to keep projects in a single Git branch and use traditional Azure deployments (not automatic Git publishing).

Community
  • 1
  • 1
Scott Wegner
  • 7,263
  • 2
  • 39
  • 55