angular-cli in a CI/CD schenario

[snarum]

• bug report -> please search issues before submitting
• [ x] feature request
  ng version 1.1.3

I'm trying to make angular-cli fit in my continuous delivery setup, but I am having one issue with the way the bundling works.

In my initial setup I had a build which which did the following:

• install missing packages (npm install)
• run tests (ng tests)
• make dist folder (ng build)
  and then collected the dist folder for artifacts.

During deploy I could just copy the artifacts to my web server. This worked very well.

But then I thought, how does this setup fit when I wish to deploy to production, and want to minify and gzip my javascript? Using ng I cannot find a way to minify the artifacts, without including the source code, and running ng --prod on the source code again.

So to fix this I moved the ng build step from the build and added it to my deployment script instead, and added all source files to the artifacts of the build. This resulted in build and deploy time to go from a few seconds to 5-6 minutes on a tiny project, mostly because node_modules is included in the artifacts.

In addition to the time consuming build, with this approach is that I don't really test the same artifacts in test and prod, as I am bundling separately for each environment.

So my question is this, am I doing something stupid here? Is there better ways to do this? If not, is it possible to add an option to ng which will take an existing dist folder and gzip/minify it? This way I could add this step to deployment when targeting to Atest/prod level environments.

[hansl]

Hi @snarum,

I'm not sure I'm following one thing about your setup. When running ng build --prod, we already minify your artifacts. You shouldn't need to run anything separately. You can also using a test environment with a prod target (try ng build --environment=test --target=prod), which will minify everything but use your test environment file.

As for gzip, that should really be done by your server. Most server environments will automatically gzip your javascript. There should be no change in there. If your setup doesn't, running gzip on your dist JavaScript files will result in the same exact files being used by the browser, so there should be no change between testing locally and the version served in your production environment.

Am I missing something? If not, then running ng build --prod as part of your CD should be what you're looking for. You can also run ng serve --prod locally to debug and test your prod environment. Or ng e2e --prod to use a production version for your end to end tests.

Leaving this open but if we don't hear back from your we'll close this issue as answered.

Cheers!

[snarum]

Hi @hansl
Thanks for commenting. Never mind the Gzip, I agree that this can be left out of the build process and handled by the web server.

What I am struggling with is to see how angular-cli fits in a CI/CD scenario. In my head, the CI step should produce a set of artifacts and the CD step should put these artifacts in any given environment. If the tests are ok, the same artifacts could be promoted to another environment, say A-Test or Production. That way we know what artifacts we have tested, and can eliminate all build step bugs.

To make angular-cli fit in such a setup I have two choices:

1. produce a "dist" folder during CI with "ng build" and use these files as artifact, and during CD copy the artifacts to the destination servers.
2. don't do anything during CI and use all src files as artifacts. During CD use "ng build"

option 1 has the benefit of very small/few artifacts and fast deployment. but we have to decide at build time if we want to minify or not.
option 2 has the benefit of being able to minimize only in A-test/production, but the deployment step will become really slow as we have to restore node_modules. Bugs caused/revealed by minification can also go undiscovered until A-Test.

There is also the issue with angular-cli enviroment configs. these are packed into the artifacts in option 1, so if I choose that I have to make another .json file to store my environment specific settings.

I'm quite new to building javascript applications, so I'm trying to wrap my head around how this should be done. On server side code Release/debug builds causes similar issues.

Any comments or recommendations are appreciated.

Regards.

[hansl]

Your CI should test on every PR, then whatever CI step is used for deployment (when merged in master for example), you should run ng build --prod then pass that to your CD.

Your option 1 sounds good, but with ng build --prod instead which will use the production environment. If you have an integration environment, you probably want ng build --target=prod --environment=integration (target sets the optimization level, environment sets the environment file to use).

View ng build as building for Debug, and ng build --prod as building for Release. It's similar in a way, but not quite the same; one of our goal for the next quarter is to bring those concepts a little closer so people are less confused by them. For now though, consider these distinctions close enough for your use case.

[snarum]

Ok, but in my dream world I would build once, deploy many times. I would want to be able to reuse the artifacts from test to atest and prod if the business side or testers accepts the functionality. If I have to differentiate on --prod or not, and even --environment=test|stest|atest|prod then I have to build every time I deploy, and I can't be 100% sure that I am actually deploying the same artifacts in prod as I did in test.

In my ideal scenario environment.x.ts is included in the dist folder as files and ng would have the option to transform these into environment.js during deploy. Also minifying should be a separate option.

So what I would like is something like this:
During build:
ng build --language=fr (etc...)
(store /dist folder in artifact repository)
during deploy:
(restore /dist folder from artifact repository)
ng transform-config --environment=atest --dist-folder=/something/dist
ng minify --distFolder=/something/dist
(copy /something/dist/** to application server)

This way I can keep my artifacts small and I can deploy the same artifacts to many servers without rebuilding. I can also decide which environments I should test the minified artifacts, and deployment would be very fast.

Just my thoughts :) You can go ahead and close this issue now if you want. I realize that this is not really a problem with angular-cli, but rather a method problem.

As for Release/Debug I select either Release or Debug for a project. Testing Debug and releasing Release artifacts is just too high a risk.

Thanks for your time.

[filipesilva]

The multiple environments part of this discussion is covered in #3855 by the way. Will close this as I don't think there's any action on our part now.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}