For previous web applications I have used team city and octopus deploy to setup the Continuous integration.
I would also have a config.json where frontend config settings would get updated using octopus variables.
However it seems with angular this isn’t possible as the variable need to be set in the environment.ts before performing ng build.
I have tried to get around this by setting up a static config.json file, however this seems to cause issues with the hashing of the file in the manifest file (which I assume is generated when performing the ng build).
Just wondering if anyone else has come across this problem, and how they resolved it.
Thanks for reaching out. This is a good question and one that I have also struggled with when using Octopus for JavaScript projects. There are a couple of options here:
You could modify your build process such that ng build actually gets run from Octopus. In this case, you could use Octopus to transform the variables in your environments.ts file. This is a pretty big shift in the roles/responsibilities of TeamCity vs. Octopus, but if it’s a newer project and you don’t have much setup yet it’s an option.
I’m not very familiar with Angular, but often times frameworks will have hooks for allowing you to inject configuration in the form of environment variables, or parameters to the app when you run it: e.g. ENV_CONFIG=test node app.js. If Angular has some built in way to do this you could still use your process and then just use your Octopus variables when you run the app.
If you don’t have any sensitive variables in Octopus for your project, you could use reach out to the Octopus API and get your variables and basically do the transformation manually. This might be time consuming but at least it keeps your build process in TeamCity.
You could try something like what you’ve done already with some kind of static config.json file that you then read in when your app starts up. This could also work but you’re probably working against the framework and that can be difficult sometimes.
Before I make specific suggestions, can you provide a bit more info about your landscape of tooling/technology that you’re using? It sounds like at the very least you’re using TeamCity and Octopus. Do you also have a third party package repository? Where do you host you your source code? I just want to make sure I’m not suggesting anything that’s too far outside of any constraints of the environment you’re working within.
using team city octopus deploy and code is stored in bitbucket. Team city packs everything into a nuget pacakge and stores that package on its own nuget feed. This is the source for the octopus deployments.
We are hosting in auzre app services, which might cause other problems (have never investigated the possibility of running node on there to build frontend packages).
Keep your TeamCity project for your angular app, but instead of having it package up the assets after an ng build, just instead have it run tests (if you have any) and leave it to bundle the entire source code for the project into your nuget package and publish that package to the TeamCity internal feed.
Then in Octopus, set up a project that pulls down that package with the angular source and in that step, configure Octopus to use Structured Configuration Variables. Specify that you want to transform variables in your environments.ts file. Then in that step run npm ci, ng build, and any other build steps you need so the project is in a production ready state.
At this point, if you’re running this step on every deployment target, you can simply move the static assets into whatever folder you need so it’s served by your web server.
If you don’t want to run a full npm ci and ng build on every deployment target, you could actually have the project create another package that just contains the production build assets, push that package to Octopus’es internal feed, and have another project just deploy those assets to your web servers.
This works well if your project does not have a large infrastructure and does not have a complicated build pipeline. Obviously TeamCity will work better if your project requires many steps for a build, but if it’s really just running npm install and ng build (more or less), Octopus is perfectly capable of doing that.