Continuous Enterprise Development in Java by Andrew Lee Rubinger, Aslak Knutsen

May 14th, 2015

What is Continuous Enterprise Development?
The term Enterprise is used for the category of business software that are complex, scalable, distributed, component-based, and mission-critical.
Continuous software development is an umbrella term that describes several aspects of iterative software application development, including continuous integration, continuous delivery, continuous testing and continuous deployment – definition from

  • Continuous integration refers specifically to the process of steadily adding new code commits to source code, a concept that has evolved over the years. Originally, a daily build was the standard for continuous integration. Today, the usual rule is for each team member to submit work as soon as it is finished and for a build to be conducted with each significant change. Usually, a certain baseline of automated unit and integration testing is performed to ensure that new code does not break the build. This way developers know as soon as they’re done if their code will meet minimum standards and they can fix problems while the code is still fresh in their minds. An important advantage of continuous integration is that it provides developers with immediate feedback and status updates for the software they are working on.
  • Continuous delivery builds on continuous integration and as with continuous integration, each code commit is automatically tested at the time it is added. In addition to the automated unit and integration testing, a continuous delivery system will include functional tests, regression tests and possibly other tests, such as pre-generated acceptance tests. After passing the automated tests, the code changes are sent to a staging environment for deployment.
  • Continuous testing adds manual testing to the continuous delivery model. With continuous testing, the test group will constantly test the most up-to-date version of available code. Continuous testing generally adds manual exploratory tests and user acceptance testing. This approach to testing is different from traditional testing because the software under test is expected to change over time, independent of a defined test-release schedule.
  • Continuous deployment adds more automation to the process to the software development process. After passing all the automated delivery tests, each code commit is deployed into production as soon as it is available. Because changes are delivered to end-users quickly and without human intervention, continuous deployment can be seen as risky. It requires a high degree of confidence both in the existing application infrastructure and in the development team. Continuous deployment is frequently seen in consumer-facing Web and mobile applications that frequently push updates to their customers as a part of the value that they bring.

The Authors
Andrew Lee Rubinger is an advocate for and speaker on open, testable enterprise Java development, member of the JBoss Core Development Team and Technical Lead of the ShrinkWrap project.
Aslak Knutsen is the project lead of Arquillian, is a Senior SoftwareEngineer at JBoss, by Red Hat. He’s involved in projects such as Arquillian, ShrinkWrap, Weld and Seam 3, and one of the founders of the JBoss Testing initiative.

About The Book
The are various tools explained and used as example for continuous development and testing in this book. Other than JBoss products such as JBoss Forge, JBoss EAP, other important tools such as Maven, Git, Arquillian, ShrinkWrap, OpenShift, Selenium, QUnit and AngularJS are used for the example project.
The book introduces its readers to the importance of proactive error handling and software quality that is the practice in recent software development.
It introduces JUnit and TestNG as test frameworks among the suggested tools as a test plaform for Java EE applications.
The book came along with a great example web application – GeekSeek that is publicly available at
Chapters 5,6, and 7 provides some examples about testing the persistence and business layer while chapter 8 has some good information about REST services. It is crucial to know the stages of REST maturity level used in application, as most developers would misunderstood that their applications are RESTful just because the application is making calls with HTTP methods to some resource URIs.
The book then moved on to making the example application testable on the UI layer and guide readers to have the web app deployed automatically via Jenkins to Openshift.

1. Continuity
2. Enabling Technologies
3. Scratch to Production
4. Requirements and the Example Application
5. Java Persistence and Relational Model
6. NoSQL : Data Grids and Graph Databases
7. Business Logic and the Services Layer
8. REST and Adressable Services
9. Security
10. The User Interface
11. Assembly and Deployment
12. Epilogue

This book is very important for modern day web and enterprise application developers to learn to make their application testable at all stages of development. The target reader of this book are experience developers and the examples and content are great to be used as a deployable project right away.
The content of this book can be sampled here, or access online at GitHub or purhased from Amazon via the following link:

Books, Java, Open Source, Review , , ,

Developer Programs

April 3rd, 2015

There are many developer programs available for software/applications/mobile developers nowadays to support and enable developers to integrate or even build applications using their APIs .
Here’s a list, sourced from DZone, in alphabetical order:

  1. ActiveState Code –
  2. Amazon Developer –
  3. Android Developer –
  4. Apple iOS Developer –
  5. AT&T Developer Program –
  6. AutoDesk Developer Network –
  7. Avaya DevConnect –
  8. BestBuy APIs –
  9. Bluetooth SIG Developer Showcase –
  10. Braintree Developer Program –
  11. Carriots –
  12. Cisco DevNet –
  13. DocuSign Developer Program –
  14. Dolby Developer Program –
  15. Embarcadero Developer Program –
  16. EMC CODE –
  17. EVRYTHNG Developers –
  18. Facebook Developers –
  19. Ford Developer Program –
  20. GitHub Developer Program –
  21. Google Developers –
  22. IBM developerWorks –
  23. Intel DeveloperZone –
  24. Intuit Developer –
  25. Magnolia Community –
  26. MapR Developer Central –
  27. Microsoft BizSpark –
  28. MongoDB Masters –
  29. Mozilla Developer Network –
  30. MuleSoft //Dev –
  31. Oracle Technology Network –
  32. OutSystems Developer Community –
  33. Philips Hue Developer Program –
  34. Qualcomm Developer Network –
  35. Rackspace Developer+ –
  36. Red Hat Enterprise Linux Developer Program –
  37. Red Hat JBoss Developer Program –
  38. SalesForce Developers –
  39. Samsung Developer Program –
  40. SAP Developer Program –
  41. Shopify Partner Program –
  42. Twitter Developers –
  43. Verizon M2M Developer Program –


Software, Technology

Running JUnit tests in Maven with Surefire Plugin and skipTests in default packaging

March 3rd, 2015

Further to the JUnit test we have created, it’s time to have it built into a maven build script so that the test can be run.
Once you have JUnit in your pom.xml file, maven will run tests with JUnit and all valid JUnit test classes under src/test/java directory.
However if you are using more than one test framework such as both TestNG and JUnit, you will need to explicitly specify JUnit as the test provider.


For the default maven packaging, you might not want to run test and the tests can be run as a separate job/task.
To address this, all you need to do is create a skipTests property in the pom.xml and have it set to false only when you need to run the tests.


Use skipTests in the configuration element.


To run the tests:
mvn test -DskipTests=false

Java, Software , ,