Continous Integration - a summary

Reference to Martin Fowler's great article Continuous Integration , I liked to summarize some of most important points in the article along with the main steps that a developer should follow in his daily process according to my understanding from the article

What is it?

software development practice where members of a team integrate their work frequently (at least daily)

Benefits of CI:

1.       reduced risk (frequent tests and integration for small changes)

2.       Have a predictiction how long integration it will take

3.       See how far you are through the process

4.       Easier to find bugs (depends on the efficiency of unit tests)

       Daily routine:

1.       Everything should be stored to the Source code management tool (code + properties files+ DB schema + DDLs for DB configuration + install/build scripts  + libraries + last stable executable) à If using a virgin machine, do a checkout, and be able to fully build the system

2.       Take a copy from the source code management  (GIT for ex) mainline (master in case of GIT) to  your machine.

3.       Make your changes + unit tests (Self-Testing code  , TDD preferred)

4.       Build + test

5.       Commit to mainline now (or make a separate branch till integration tests pass)

6.       Should build (a fast build) on integration server (Clone of the Production Environment) after each commit (don’t go home before it succeeds)

7.     Fix Broken Builds Immediately (top priority) : if reason not obvious, rollback then fix, don’t debug.

       Rules and Tips:

-          Each build must be accompanied with running unit tests. 
-          Should commit to the mainline daily at least. 
-          Deployment can be automated (preferred) with scripts to deploy /rollback  applications into any environment easily, or manual (if automated is slow)

-          If you are not using CI , you can start first with nightly builds

-          Commit build must be fast (10 minutes ) ,To achieve this, 1) break down the system to smaller parts - 2)  the deployment tests (which take most of the time)can be divided into 2 categories (thus 2 environments) : main short tests(no DB hits) that is run with the commit build and heavy lengthy tests that can run afterwards (after I guarantee a correct build) , this is called deployment pipeline

-          make sure there's a well-known place where people can find the latest stable executable.

-          All people should be able to see build status.

-          Integration environment should be a Clone of the Production Environment (OS ver, DB ver, IPs, all libs, same HW) : every difference results in a risk that what happens under test won't happen in production.

-          you need multiple environments, one to run commit tests, one or more to run secondary tests + prod

-          good ideas for deployment : 1) deploying a trial build to a subset of users – 2) In clustered environments ,deploy to one node at a time

**This is to claim that I took all the info from the mentioned article and that the article's author is not responsible of this summary

ClassCastException: Proxy_4 cannot be cast to Xxxxx

I encountered that error in RMI client side in EJB and the problem was in the EJB side actually .... I changed some jars in the shared library -that other apps use and needed this change- the EJB reads from, so something wrong happened in the EJB project -but nothing appeared in the log- so when
I fixed this and made a separate lib for the EJB.... every thing worked fine.

IllegalArgumentException: XxxxxBean stateless session

I encountered this error in RMI client side ... the reason was that something changed on the EJB side that required a restart in the client side ... so after I restarted the client side application the issue was resolved

Gson StackOverFlowError

This usually happens when the class you are converting to json refers to itself ..... most commonly when you are using jpa entities with one to many relations ... where parent refers to many children and child refers again to its parent so that you are able to cascade updates.

Solutions :
1- make the variable in the child transient ... but won't work in case of JPA , because you need the entity attributes not transient
2- make another DTO for JSON transfer that doesn't contain this cyclic dependency and map from/to it ...... but too much effort and error prone
3- the clean way : exclude the variable from parsing by gson , how ? mark all attributes that you want it to be parsed with @Expose annotation .... and then on creation of json object use : 


GsonBuilder.excludeFieldsWithoutExposeAnnotation().create()

Now the non exposed attribute won't be converted in json

Don't increase compiler error level .... Or at least think well before doing that

You might think ..... Oh yeah, I don't want a tiny small error in my application, neither a small warning and worse -not the concept but your reaction- I want to stick to coding standards ,  so I will raise the compiler error level to consider every inconvenience as a nice red error ...... And yes don't worry I am already using maven so I don't really depend on these errors in my productivity.

Don't do it .... I advice

By time, and when your team member size increases and the application gets older and older with many people might successively commit changes to the same portion of code and every one putting his nice touch, you will get used to the 21342235123523 errors appearing in your error console and simply you will never look at it .... and the red color in your code will be as normal as the blue color of the sky.

And this has two -or may be more- draw backs :

1- You won't like looking to your code
 And more importantly :
2- The real problems and errors will hide in the pile of fake errors and are not always easy to figure out using other compilers.... build path errors of dependencies are one of the examples.

Remove org.apache.http.wire logs

Remove org.apache.http.wire logs

I was trying to run test cases that connects to SOLR – or uses any sort of http request- using JUnit, I could see many log lines starting with

DEBUG org.apache.http.wire

This heavy logging causes inaccurate results if you are concerned with measuring performance or calculating time span for a certain http request  ... for example a request that takes actually 1 second appears in the eclipse console to take 6 seconds !!

To remove these logs , do the following :

11 -  In ur TestCases class put these imports:

import org.slf4j.LoggerFactory;

import ch.qos.logback.classic.Level;

import ch.qos.logback.classic.Logger;       

22 -  In the start of the test method, put the following code lines

Logger root = (Logger)LoggerFactory.getLogger(Logger.ROOT_LOGGER_NAME);

root.setLevel(Level.ERROR);

33 -  In your pom.xml, put

       <dependency>

              <groupId>ch.qos.logback</groupId>

              <artifactId>logback-classic</artifactId>

              <version>1.0.13</version>

</dependency>

Or if you u already have this dependency, just remove the following line -if exists-

              <scope>runtime</scope>

in order to compile.

Hope it helps