Continuous Integration- it might be the last thing I'm lacking that is preventing me from developing in a truly agile, world class programmer level. Nobody loves automated testing more than me, and so I was naturally by this concept of having the unit and e2e tests run each time the code is pushed to the git repo.
Travis.yml - A Fancy Way to Control a Linux Box
If you look closely at the output of the logs on the travis ci website, you can see that the first line is this:
Using worker: worker-linux-docker-6aae7592.prod.travis-ci.org:travis-linux-4
This is interesting because it seems like travis is using a linux box with docker containers to run your tests. So at a very high level, what are we trying to do here? It all starts from a push to your git repo. When travis is enabled your code will be automatically sent to travis's linux container to have the tests run. The tests will then either fail or pass, and you can see the final status on the travis site. I;m sure 100% sure if it was this post that gave me the idea, but indeed Travis CI is a wealth of automation. Indeed, under the script: block in your travis.yml file you basically list a series of linux commands for it to execute one after the other. Run your unit tests, run your build, push from dist, and that's continuous integration! *large crowd cheering in the background*
Set Up The Box's Environment
The travis.yml file allows you to tell the travis linux box the exact commands to run. Similar to if you clone the repo fresh, you'll need to give it some set up commands like "bower install". Here is a basic travis.yml file that I used to run my unit tests:
sudo: false language: node_js node_js: - "0.12" - "0.10" - "iojs" script: - 'npm install bower' - 'bower install' - "gulp test" after_script: - "npm install coveralls@2.11.x && cat coverage/lcov.info | coveralls" matrix: fast_finish: true notifications: irc: channels: - "irc.freenode.org#unshift" on_success: change on_failure: change
Run the Unit Tests
In the example travis.yml file above we can see the linux commands being run in the "script:" area. The gulp test command is what my project normally uses to run unit tests. Having your process "Exit with 0" is a good thing.
Get a Passing Build!
It's a great feeling when you push a build that finally passes all tests! Make sure the unit tests are passing locally before pushing to ensure that they should actually be passing! When you have problems look at the Travis.org logs to see if one of your processes is exiting with a non-zero code (and should be in red text as well). Try commenting out lines in your scripts block (use # to comment in yml) to pinpoint which command is causing your issues.
Next Steps: Completing the Pipeline...
We've done a lot here, but there's still plenty more to do. Although we have set up Travis CI and configured it to run our unit tests, that's just the beginning. In order to fully complete the loop and go from CI to CD (continuous deployment) we just need to add a script to our travis.yml that tells it to push the files in our dist/ folder to the final place where our site is to be hosted (in my personal projects' case normally the gh-pages branch). Also, we could have travis run our e2e Protractor tests. This can get a little tricky since e2e tests need an actual browser to run inside of. Luckily, we can use tool like "sauce labs" to hook up e2e testing with Travis, and you can the added benefit of being able to test it on an actual instance of pretty much any browser / platform you can imagine. nice! If we wanted to get really particular about regression, we could even unit test our css! I attended a meetup event one time about Hardy.io and Percy.io, two different "visual regression testing" tools for basically unit testing your css! There's a lot you can do with CI, and if you're not using it now then I think you'll be really glad once you add it to your workflow.
|
|
RSS Feed