Continuos Integration

Continuos Integration, and continuos delivery

Boost quality and productivity Using Grunt as a continuous development tool

Continuous development of the Front End Tier based on Grunt (node.js)

The development of the User Interface (Front End Tier) requires science  and art to work together. To make it works, the process and tools are: Grunt continuous integration.

The Benefits:

Using Grunt as a continuous development tool for the front end tier I’ve Improved the quality:

  • Using the best practices
  • allowing to have metrics with static analysis on css, html & js
  • support a BDD (Behavior Driving Development) with unit tests and code coverage of the JavaScript code.

Boost the productivity:

Development Process with Grunt

Development Process with Grunt

1) At any change in the code when saving the files, the files are compiled or processed

  • Stylus -> css files
  • CoffeScript -> JS Files

2) The validation tools are launched

  • Jshint,
  • csslint,
  • lint5

3) The unit tests are launched

4) The files are copied to Development Web Server

5) The browser reloads the changes.

The plugins are:


  1. Stylus
  2. Css lint (static code quality analysis)


  1. CoffeeScript
  2. Jshint (static code quality analysis)
  3. Jasmine (unit tests)
  4. grunt-template-jasmine-istambul (code coverage


  1. lint5 (static code quality analysis)

To handle the development process:

  1. Watch
  2. Connect (enables a webserver)
  3. Proxy-Connect (enables a proxy to invoke remote ajax calls)

To handle the delivery process

  1. htmlmin
  2. Copy
  3. cssmin
  4. regex-replace
  5. uglify

Unit Testing?

Much more better, I followed Behavior-Driven development process. The platform I used over Grunt is Jasmine. Why? It is simple to configure, runs on top of phantomjs browser engine, and enables to implement the code coverage.

Coding JavaScript?

Much more better, I used CoffeScript. The benefits are: better code quality, boost the productivity using the good parts of JavaScript. The generated code is 100% jslint clean code, improves the readability and the code needs to be compiled that guarantees the code is free of syntax and typos errors.

Lessons learned.

  1. Start always with a BDD: testing with Jasmine provides a better design, ensuring the testability of the code and using the best practices with MVC pattern on the frontend.
  2. CSSLint provide a great feedback to improve the quality of the css.

Next steps on my process:

  1. Integrate Grunt with a CI server (Jenkins).
  2. Integrate the metrics reports provided by Grunt on a historical dashboard: SonarQube
  3. Implement applications with I18N (internationalization).


Using Grunt as a continuous development tool, developing the user interface the right process and tools, allows to improve the productivity and the quality. In less than 2 weeks, I implemented the process, I learned 2 new languages (Coffeescript & Stylus) and I deliver a great project. Don’t hesitate to start using Grunt continuous integration of the UI.





How to backup uncommitted changes locally using Subversion: svn status, sed 1

Discover the power of subversion and bash with sed, tar and xargs:

svn status provided the information about the modified files

$svn status

  • using sed, we can get the list of modified files.

$mkdir backup1 $ svn status|sed -e s/”M “// -e s/^?.*// -e ‘/^$/ d’ |cp

$ svn status|sed -e s/”M “// -e s/^?.*// -e ‘/^$/ d’|xargs -n 1 -I {} echo .{} backup1/

  • The final command:

$ svn status|sed -e s/”M “// -e s/^?.*// -e ‘/^$/ d’|sed s/\///g|xargs -n 1 -I {} cp ./{} backup1/

  • or a cleanest:

$ svn status|sed -n s/”M “//p |sed s/\///g |xargs -n 1 -I {} cp ./{} backup2/

  • instead to copy the files loosing the folder structure, we can use the tar program:

$ svn status|sed -n s/”M “//p |sed s/\///g |xargs -I {} tar -u -f backup2/archive.tar {}

  • If I want ot see the time or use it to create the file, I can use the function date: $echo $(date “+%Y-%m-%d@%T”) 2014-01-22@16:50:47

$ svn status|sed -n s/”[M|A] “//p |sed s/\///g |xargs -I {} tar -u -f backup2/$(date “+%Y-%m-%d”)-$(date +%s).tar {}

To revert the changes:

$ svn status|sed -e s/”M “// -e s/^?.*// -e ‘/^$/ d’|sed s/\///g|xargs -n 1 -I {} svn revert {}

  • references:

  • Going further: a script that commit the changes, before commit it, backup the changes, later add the diff and finaly add the logs to the backup file:

#We need the folder where will be saved the backup file first param #$ svn status|sed -n s/”[M|A] “//p |sed s/\///g |xargs -I {} tar -u -f backup2/$(date “+%Y-%m-%d”)-$(date +%s).tar {} #We need the message we will use on the commit #We need to know the revision number: svn info provide it. #We need to know the difference #$ svn diff > diff_2014-01-24-1390590293.txt

fileNameWithoutExt=$(date “+%Y-%m-%d”)-$(date +%s) tarFileName=$(fileNameWithoutExt).tar fullTarFileNameWithPath=$1/$tarFileName svn status|sed -n s/”[M|A] “//p |sed s/\///g |xargs -I {} tar -u -f $fullTarFileNameWithPath {} svn diff > diff_$(fileNameWithoutExt).txt tar -u -f $fullTarFileNameWithPath ./$diff_$(fileNameWithoutExt).txt svn commit -m $2 revisionNumber=svn info|sed -n ‘s/Revision: //p’ svn update svn log -r $revisionNumber > $fileNameWithoutExt.log tar -u -f $fullTarFileNameWithPath ./$fileNameWithoutExt.log


svn status