Deploy Angluar Application to Azure Slots

Hi all,

I m an Octopus Deploy newbie as I literally set it up 10 minutes ago. I have integrated it with our TeamCity and I have a question.

Up until now we had our Frontend code as one build configuration for Continuous Integration. That one was running grunt to prepare a package for Staging deployment and grunt again (different parameters) to prepare a package for Production deployment as the two environments are different (different configuration / endpoints etc). Those artifacts were then discovered by the deployment processes.

What’s the best way of doing this with OctopusDeploy? How can (and should) I package those artifacts as two different NuGet packages and if so what’s the way to achieve that given those arent .NET projects and therefore don’t have nuspecs or csprojs


Hi Yannis,
First off let me start by saying that NuGet is agnostic to .Net and will happily package up whatever files you need given a .nuspec file. Check out their documentation for details of using their command line.

Secondly, I have to sat that the recommended way of preforming Continuous Integration with Octopus Deploy is to build once, deploy many. What this means is that the build that is “compiled” (in the loosest sense of the term when it comes to front-end JS code) and tested against in Staging and UAT environments should be the same code that is deployed to production. In this way you get the confidence of knowing that there are no “ostensibly” harmless differences between your test area and production that remain untested until in use by your end user.
What are the major build differences between your staging and production builds? For front-end code I could imagine that you might want to only minify the .js files going to production servers to allow for debugging etc in test environments. If this is the case then I would recommend using the same concatenated and minified scripts in staging, but also generate source map files to allow you to debug easily in the browser. These could be optionally removed during the production deployment process.

That being said it is obvious that there are likely to be configuration or connection details that need to differ between environments, and Octopus Deploy has several mechanisms for supporting this.
Again, our documentation is the best source for information about these topics.
Substituting variables in files is the easiest way to use the variable substitution syntax to get the right variables configured in Octopus Deploy into your code at deployment time. This powerful Variable feature allows you to scope their values to targets, environments or several other dimensions to ensure you have the finest grain control on the end result.
Alternatively you can leverage the configuration transformation feature that you may be familiar with from projects to transform a XML file at deployment time.

Ultimately I would reccomend packaging your compiled JS code into a NuGet package using NuGet.exe and a nuspec file then pushing that into Octopus Deploy from TeamCity using our TeamCity Plugin. Using Octopus Deploy variables you can then push to whichever environment you need using variables to set the deployment up for the specific scenario in question.
I hope this gives you some thought about how you might go forward with your deployment but if you have any further questions please feel free to drop us another line.