AngularJS CI Server Overview
Articles,  Blog

AngularJS CI Server Overview


Hi, everybody. This is Igor from the
AngularJS team. And I would like to show you
our CI, or Continuous Integration server which we use
to be very productive when building AngularJS. AngularJS is a JavaScript
framework and as such must be tested in multiple browsers,
across multiple operating systems, which is quite a tricky
and laborious task and it only makes sense to automate it as much as possible. So for this reason we set up CI
server which runs Jenkins on a remote Mac server somewhere
in the datacenter. And it watches a good
[? number ?] of repositories and whenever there are changes
so pushed to the repositories, it runs all the tests
and builds Angular. So I’m going to go kick off
one of the jobs manually, since I have nothing to
[? comment ?] right now. And what I’m looking at right
now is the VMC session to the remote server. And I see all these browsers
starting and going away. You can observe that we have
local browsers as well as browsers in virtual machines
like this one and a WindowsXP virtual machine running IE 8. We also have IE 9 and the
Windows 7 virtual machine. And all of these browsers are
running unit tests as well as end to end tests. The way this works is, we
utilize JS test driver. JS test driver is a remote
Javascript console. It’s a small Java server that
can start browsers, capture them, dispatch unit tests to
be executed in all of these browsers, and then collects
all the results. We set up Jenkins to run JS test
driver and we can check out what that looks like. So this is the upload to
the console output. And this is output from the JS
test driver, so each of these dots is a single passing test.
So every time, a test goes green, a little dot
is printed here. And then at the end, we have a
collection of– a summary of all the results. So we can see how long it took
to run tests on each of the browsers and how many tests
passed or failed. In this case all of the
tests are passing. So we have a suite of about a
thousand unit tests and since Angular can work in two modes
with JQuery and without JQuery, we run the tests– both unit tests and end to end
tests with and without JQuery. So in addition to unit tests, we
also have end to end tests. And end to end tests– we have a local node server
which starts up our documentation application and
the end to end tests navigate to individual pages. So of this the documentation
application and look for these live examples and interact
with them. So in the case of this currency
filter, the test just comes here and types some kind
of– some number in the input field and then asserts that
the output was formatted according to the rules set out
in the test. And this happens for all of the pages. So, JS test driver exports then
all of the test results in the JUnit format. And then we have a JUnit plugin
for Jenkins which can graph all the test
result trends. As well as in case of some
failing builds, it can tell us which builds are failing. So we have three IE 7
tests failing here. So we can see here that we have
multiple jobs set up. We have one job that monitors
the main master branch and makes sure that it’s
always green. Then we also run the
same tests on IE 7. We kind of singled it out,
because it’s kind of tricky to keep IE 7 happy and the
build is not green all the time there. So it’s separated from
everything else. Then we have a job here for the
last stable branch, which we keep green at all times. And then we have a bunch of
developer specific jobs. These jobs monitor the entire repository of a given developer. And whenever a developer
pushes a new branch, or comments to an existing branch,
Jenkins will notice that and will create a build
and run all tests. This is super useful when
we do pull requests and [? store ?] we review
[? reincode ?] that is about to be merged
with the master branch. Because by the time we get to do
the review, we already have the results from Jenkins. and we can tell if the changes
that are about to be merged are passing all tests. And that really speeds
up the development. It also keeps all
the developers honest about their code. Another nice thing here is
that for each of the successful builds, we publish
build artifacts. And what I can do is
I just copy a link. And if a bug was reported, for
example, through jsFIDDLE, I can just go and update the
example with the latest build, rerun it, and then I can show,
hey the latest build is passing this test so
we fixed the bug. That’s really cool. OK, my build just finished
running. And what I can see here
is that it succeeded. The build is green and I can
also quickly check and I see that we just finished running
about 14,000 tests. So that’s all the unit tests
running on each of the seven browsers with JQuery,
without JQuery. And in addition to that, end
to end tests are running in all browsers with and
without JQuery. So that’s quite a lot of stuff
that happened in the last to five or six minutes. I hope you really like
this because it’s very helpful for us. And I hope it’s going to
inspire you to set up something similar for
your project. Thanks for watching. Bye bye.

4 Comments

  • Craig Squire

    Hi,
    Do all of your Jenkins jobs use the same jstd server?
    Assuming it does, does it handle it well when multiple big test jobs are thrown at it?
    Does your jstd server need restarted often?
    Thanks!

  • Igor Minar

    The jstd server is started for each job, actually I configured it to start for the first set of unit tests, then shut down, then start with a different configuration and different tests, shut down and then I start it one more time and run the e2e tests and shut it down. In my experience JSTD is unfortunately too flaky to have it running persistently.

Leave a Reply

Your email address will not be published. Required fields are marked *