4

I'd like to get some knowledge/thoughts on a situation that is related to my recent experience.

In my current project we are using the same setup, Angular-cli for building the production-ready bundles, using teamcity to execute these commands and Octopus Deploy for distributing the packages. But we have encountered some issues with deploying for different environments.

The situation

We have 4 environments on our Azure: Dev,Test,Staging and production. What we would like to is that everytime our master branch is pushed, that TeamCity builds the application, pushes it to octopus with automatic deploy to Development and via the Octopus webapp promote it to the other environments.

We also have 4 environments for the backend on Azure, each with its own IP adress.

Approach 1

This approach is very clean from the Angular perspective but not at all from the Teamcity --> Octopus, single package for all environments.

In this approach we have different environement.ts files with the configured API endpoints that our service use.

On each push our Teamcity executes a ng build for each environment, creates a package for that build and pushes it to octopus. So that octopus gets 4 packages for each build that it can deploy to the right environment on Azure.

From an angular perspective this works great, the local developper never has to do any local changes before commiting code + the endpoint are baked within the deployment packages.

But from an Teamcity --> Octopus perspective this is not clean, the combination of these platform is made so that Teamcity makes 1 package per code push and then Octopus deploys that package (and does some file transformations with variabeles for the different environments) to the different environments.

Approach 2

The second approach is good for The Teamcity --> Octopus part. In our Angular App we write a service for getting the application settings such as the API endpoint from a .json file in the /assets folder.

This approach is great because Teamcity can build 1 package and then the Octopus can manipulate the .json file from the assets of the package.

But this approach doesn't quite sound bulletproof since we are doing a http request to get our application settings, while we feel that these things should be baked in the application.

I'd like to get some insights on these approaches, since I'm not a pro in Angular-Teamcity-Octopus combination and I'd like to know if anyone has encountered this situation and what the 'silver bullet' could be.

Community
  • 1
  • 1
Cédric Berlez
  • 161
  • 1
  • 8
  • 1
    Maybe similar to https://stackoverflow.com/questions/46441288/how-to-build-once-and-deployed-multiple-environments-using-angular-cli-4/46443856#46443856? – Moema Oct 06 '17 at 06:07
  • I think that is exactly what I was searching for, but could not find anywhere, gotta work on my search skills... Thank you! – Cédric Berlez Oct 06 '17 at 06:11
  • You're welcome :) – Moema Oct 06 '17 at 06:12
  • Possible duplicate of [How to build once and deployed multiple environments using angular-cli 4?](https://stackoverflow.com/questions/46441288/how-to-build-once-and-deployed-multiple-environments-using-angular-cli-4) – Cédric Berlez Oct 06 '17 at 06:13
  • very useful question thx. – jay Dec 20 '17 at 21:09

0 Answers0