Jenkins Description Setter Plugin for Improving Continuous Delivery Visibility

In Continuous Delivery each build is potentially shippable. This fact implies among a lot of other things, to assign a none snapshot version to your components as fast as possible so you can refer them through all the process. I suggest creating a release branch, assign the version to the project and then start the typical pipeline (compile, tests, code quality ...) steps to release branch.

If you are using Jenkins, your build job screen will look something like:

Note that we have released the project many times, but there is no quick way to know exactly which version has been constructed in build number 40. To avoid this problem and having a quick overview of which version has been executed in each build job instance, we can use Jenkins description setter plugin. This plugin sets the description for each build, based upon a regular expression of the build log file.

So your build job screen will look something like:

Much better, now we know exactly the result of a build job and which product version has been generated.

So first step is installing the plugin by simply going to:

Jenkins -> Manage Jenkins -> Manage Plugins -> Available

After installation you can open Build Job configuration screen and add a post-build action called "Set build description". Then add a regular expression for extracting the version number. In this case the regular expression is:

\[INFO\]         from version 0\.0\.1-SNAPSHOT to (.*)

Take a look at next fragment of build log file:

[INFO] Scanning for projects...

[INFO]                                                                         

[INFO] ------------------------------------------------------------------------

[INFO] Building hello 0.0.1-SNAPSHOT

[INFO] ------------------------------------------------------------------------

[INFO] 

[INFO] --- versions-maven-plugin:2.0:set (default-cli) @ hello ---

[INFO] Searching for local aggregator root...

[INFO] Local aggregation root: /jobs/helloworld-inital-build/workspace

[INFO] Processing com.lordofthejars.helloworld:hello

[INFO]     Updating project com.lordofthejars.helloworld:hello

[INFO]         from version 0.0.1-SNAPSHOT to 1.0.43

Props: {project.version=1.0.43, project.artifactId=hello, project.groupId=com.lordofthejars.helloworld}

At line 12 we are logging the final version of our product for current pipeline execution, so we create a regular expression which parses that line and the part between brackets are used as decorator.

Depending on log traces the regular expression will differ from this one. In this case, we are always using the same SNAPSHOT version in development and only when product is going to be released (this could be 3 times per day or every night) the final version is generated and set.

Hope this plugin helps you to make your builds more clear.

We keep learning,
Alex.

Yellow diamonds in the light, And we're standing side by side, As your shadow crosses mine (We Found Love - Lindsey Stirling)

Music: http://www.youtube.com/watch?v=0g9poWKKpbU

NoSQLUnit 0.7.3 Released

NoSQLUnit is a JUnit extension to make writing unit and integration tests of systems that use NoSQL backend easier. Visit official page for more information.

In 0.7.3 release, next changes has been added:

• Support for Infinispan.
• Adding the possibility to add custom insertion and comparison methods for each engine. Thanks to Bob Tiernay for the idea. https://github.com/lordofthejars/nosql-unit/issues/45
• Adding the possibility to avoid NoSQLUnit injects fields annotated by @Inject by using @ByContainer annotation.  Very useful for Spring Framework Tests, Arquillian Tests or Needle Tests.
• Removed JMockMongo as embedded Mongo implementation for Fongo project. Users should not notice any difference from the point of view of NoSQLUnit. Thank to Bob Tiernay for providing this valuable information about Fongo.
• Updated mongo-java-driver to 2.10.1.
• Updated neo4j to 1.8.
• Fixed bug #46 thanks to MrKeyholder for discovering and attaching the solution code.

We keep learning,

Alex.

Fiery mountain beneath the moon, The words unspoken, we'll be there soon, For home a song that echoes on, And all who find us will know the tune. (The Lonely Mountain - Neil Finn)

Music: http://www.youtube.com/watch?v=iIy5zvSpF1E

Testing Spring Data MongoDB Applications with NoSQLUnit

Spring Data MongoDB

Spring Data MongoDB is the project within Spring Data project which provides an extension to the Spring programming model for writing applications that uses MongoDB as database.

To write tests using NoSQLUnit for Spring Data MongoDB applications, you do need nothing special apart from considering that Spring Data MongoDB uses a special property called _class for storing type information alongside the document.

_class property stores the fully qualified classname inside the document for the top-level document as well as for every value if it is a complex type.

Type mapping MappingMongoConverter is used as default type mapping implementation but you can customize even more using @TypeAlias or implementing TypeInformationMapper interface.

Application

Starfleet has asked us to develop an application for storing all logs of starship crew members into their systems.

To implement this requirement we are going to use MongoDB database as backend system and Spring Data MongoDB at persistence layer.

Log documents have next json format:

Example of Log Document

{ "_class" : "com.lordofthejars.nosqlunit.springdata.mongodb.log.Log" , "_id" : 1 , "owner" : "Captain" , "stardate" : { "century" : 4 , "season" : 3 , "sequence" : 125 , "day" : 8 } , "messages" : [ "We have entered a spectacular binary star system in the Kavis Alpha sector on a most critical mission of astrophysical research. Our eminent guest, Dr. Paul Stubbs, will attempt to study the decay of neutronium expelled at relativistic speeds from a massive stellar explosion which will occur here in a matter of hours." , "Our computer core has clearly been tampered with and yet there is no sign of a breach of security on board. We have engines back and will attempt to complete our mission. But without a reliable computer, Dr. Stubbs' experiment is in serious jeopardy." ] }

This document is modelized into two Java classes, one for whole document and another one for stardate part.

Stardate class

@Document public class Stardate { private int century; private int season; private int sequence; private int day; public static final Stardate createStardate(int century, int season, int sequence, int day) { Stardate stardate = new Stardate(); stardate.setCentury(century); stardate.setSeason(season); stardate.setSequence(sequence); stardate.setDay(day); return stardate; } //Getters and Setters }

Log class

@Document public class Log { @Id private int logId; private String owner; private Stardate stardate; private List<String> messages = new ArrayList<String>(); //Getters and Setters }

Apart from model classes, we also need a DAO class for implementing CRUD operations, and spring application context file.

MongoLogManager class

@Repository public class MongoLogManager implements LogManager { private MongoTemplate mongoTemplate; public void create(Log log) { this.mongoTemplate.insert(log); } public List<Log> findAll() { return this.mongoTemplate.findAll(Log.class); } @Autowired public void setMongoTemplate(MongoTemplate mongoTemplate) { this.mongoTemplate = mongoTemplate; } }

application-context file

<?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:context="http://www.springframework.org/schema/context" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.1.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.1.xsd"> <context:component-scan base-package="com.lordofthejars.nosqlunit.springdata.mongodb"/> <context:annotation-config/> </beans>

For this example we have used MongoTemplate class for accessing to MongoDB to not create an overcomplicated example, but in a bigger project I recommend use Spring Data Repository approach by implementing CrudRepository interface on manager classes.

Testing

As has been told previously, you don’t have to do anything special beyond using class property correctly. Let’s see the dataset used to test the findAll method by seeding _log

collection of logs database.

all-logs file

{ "log":[ { "_class" : "com.lordofthejars.nosqlunit.springdata.mongodb.log.Log" , "_id" : 1 , "owner" : "Captain" , "stardate" : { "century" : 4 , "season" : 3 , "sequence" : 125 , "day" : 8 } , "messages" : [ "We have entered a spectacular binary star system in the Kavis Alpha sector on a most critical mission of astrophysical research. Our eminent guest, Dr. Paul Stubbs, will attempt to study the decay of neutronium expelled at relativistic speeds from a massive stellar explosion which will occur here in a matter of hours." , "Our computer core has clearly been tampered with and yet there is no sign of a breach of security on board. We have engines back and will attempt to complete our mission. But without a reliable computer, Dr. Stubbs' experiment is in serious jeopardy." ] } , { "_class" : "com.lordofthejars.nosqlunit.springdata.mongodb.log.Log" , "_id" : 2 , "owner" : "Captain" , "stardate" : { "century" : 4 , "season" : 3 , "sequence" : 152 , "day" : 4 } , "messages" : [ "We are cautiously entering the Delta Rana star system three days after receiving a distress call from the Federation colony on its fourth planet. The garbled transmission reported the colony under attack from an unidentified spacecraft. Our mission is one of rescue and, if necessary, confrontation with a hostile force." ] } ... }

See that _class property is set to full qualified name of Log class.

Next step is configuring MongoTemplate for test execution.

LocalhostMongoAppConfig

@Configuration @Profile("test") public class LocalhostMongoAppConfig { private static final String DATABASE_NAME = "logs"; public @Bean Mongo mongo() throws UnknownHostException, MongoException { Mongo mongo = new Mongo("localhost"); return mongo; } public @Bean MongoTemplate mongoTemplate() throws UnknownHostException, MongoException { MongoTemplate mongoTemplate = new MongoTemplate(mongo(), DATABASE_NAME); return mongoTemplate; } }

Notice that this MongoTemplate object will be instantiated only when test profile is active.

And now we can write the JUnit test case:

WhenAlmiralWantsToReadLogs

@RunWith(SpringJUnit4ClassRunner.class) @ContextConfiguration(locations = "classpath:com/lordofthejars/nosqlunit/springdata/mongodb/log/application-context-test.xml") @ActiveProfiles("test") @UsingDataSet(locations = "all-logs.json", loadStrategy = LoadStrategyEnum.CLEAN_INSERT) public class WhenAlmiralWantsToReadLogs { @ClassRule public static ManagedMongoDb managedMongoDb = newManagedMongoDbRule() .mongodPath( "/Users/alexsotobueno/Applications/mongodb-osx-x86_64-2.0.5") .build(); @Rule public MongoDbRule mongoDbRule = newMongoDbRule().defaultManagedMongoDb("logs"); @Autowired private LogManager logManager; @Test public void all_entries_should_be_loaded() { List<Log> allLogs = logManager.findAll(); assertThat(allLogs, hasSize(3)); } }

There are some important points in the previous class to take a look:

1. Because NoSQLUnit uses JUnit Rules you can use @RunWith(SpringJUnit4ClassRunner) freely.
2. Using @ActiveProfiles we are loading the test configuration instead of the production ones.
3. You can use Spring annotations like @Autowired without any problem.

Conclusions

There is not much difference between writing tests for none Spring Data MongoDB and applications that use it. Only keep in mind to define correctly the _class property.

We keep learning,
Alex.

Els astronautes volen baix, Els núvols passen com qui no diu res. Amb les butxaques a les mans, Caminarem els passos d’altres peus. (Pa amb Oli i Sal - Blaumut)

Music: http://www.youtube.com/watch?v=Hkc5piclElg