DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Please enter at least three characters to search
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Because the DevOps movement has redefined engineering responsibilities, SREs now have to become stewards of observability strategy.

Apache Cassandra combines the benefits of major NoSQL databases to support data management needs not covered by traditional RDBMS vendors.

The software you build is only as secure as the code that powers it. Learn how malicious code creeps into your software supply chain.

Generative AI has transformed nearly every industry. How can you leverage GenAI to improve your productivity and efficiency?

Related

  • DDD and Spring Boot Multi-Module Maven Project
  • Keep Your Application Secrets Secret
  • Aggregating REST APIs Calls Using Apache Camel
  • How to Activate New User Accounts by Email

Trending

  • The End of “Good Enough Agile”
  • Event Driven Architecture (EDA) - Optimizer or Complicator
  • Using Java Stream Gatherers To Improve Stateful Operations
  • MCP Servers: The Technical Debt That Is Coming
  1. DZone
  2. Testing, Deployment, and Maintenance
  3. Deployment
  4. Build Binaries Only Once for Continuous Deployment

Build Binaries Only Once for Continuous Deployment

A step-by-step guide to build binaries only once in Java with the Nexus Repository.

By 
Arun Gupta user avatar
Arun Gupta
·
Aug. 17, 15 · Tutorial
Likes (4)
Comment
Save
Tweet
Share
5.6K Views

Join the DZone community and get the full member experience.

Join For Free

One of the fundamental principle of Continuous Delivery is Build Binaries Only Once, or in short BBOO. This means that the binary artifacts should be build once, and only once. These artifacts should then be stored in a repository manager, such as a Nexus Repository. Subsequent deploy, test, and release cycles should never attempt to build this binary again and instead reuse this binary. This ensures that the exact same binary has gone through all different test cycles and delivered to the customer.

Several times binaries are rebuilt during each testing phase using a specific tag of the workspace, and considered the same. But that is still different! This might turn out to be the same but that’s more incidental. Its more likely not same because of different environment configurations. For example, development team might be using JDK 8 on their machine and the test/staging might be using JDK 7. There are a multitude reasons because of which the binary artifacts could differ. So it’s very essential to build binaries only once, store them in a repository, and make them go through different test, staging, and production cycle. This increases the overall confidence level of delivery to the customer.

Build Binaries Only Once
















This image shows how the binaries are built once during Build stage and stored on Nexus repository. There after, Deploy, Test, and Release stages are only reading the binary from Nexus.

The fact that dev, test, and staging environments differ is a different issue. And we’ll deal with that in a subsequent blog.

How Do You Setup Build Binaries Only Once?

For now, lets look at the setup:

  1. A Java EE 7 application WAR file is built once
  2. Store in a Nexus repository, or .m2 local repository
  3. Same binary is used for smoke testing
  4. Same binary is used for running full test suite

The smoke test in our case will be just a single test and full suite has four tests. Hopefully this is not your typical setup in terms of the number of tests, but at least you get to see how to setup everything.

Also only two stages of testing, smoke and full but the concept can be easily extended to add other stages. A subsequent blog will show a full blown deployment pipeline.

Lets get started!

  1. Check out a trivial Java EE 7 sample application from github.com/javaee-samples/javaee7-simple-sample. This is a typical Java EE application with REST endpoints, CDI beans, JPA entities.
  2. Setup a local Nexus Repository and deploy a SNAPSHOT of the application to it as:
    mvn deploy

    By default, Nexus repository is configured on localhost:8081/nexus. Note down the host/port if you are using a different combination. Also note down the exact version number that is deployed to Nexus. By default, it will be 1.0-SNAPSHOT. You can also deploy a RELEASE to this Nexus repository as:
    mvn release:clean release:prepare release:perform
    Note down whether you deployed SNAPSHOT or RELEASE.In either case, you can also specify -P release Maven profile and sources and javadocs will be attached with the deployment. So if RELEASE is deployed as:
    mvn release:clean release:prepare release:perform -P release
    Then sources and javadocs are also attached.
  3. Check out the test workspace from github.com/javaee-samples/javaee7-simple-sample-test. Make the following changes in this project:
    1. Change nexus-repo property to match the host/port of the Nexus repository. If you used the default installation of Nexus and deployed a RELEASE, then nothing needs to be changed.By default, Nexus has one repository for SNAPSHOTs and another for RELEASEs. The workspace is configured to use RELEASE repository. If you deployed a SNAPSHOT, then “releases” in nexus-repo needs to be changed to “snapshots”to point to the appopriate repository.
    2. Change javaee7-sample-app-version property to match the version of the application deployed to Nexus.
  4. Start WildFly and run smoke tests as:
    mvn test -P smoketest
    This will run all files ending in “SmokeTest”. ShrinkWrap and Arquillian perform the heavy lifting of resolving the WAR file from Nexus and using it for running the tests:
    return Maven.configureResolver()
           .withRemoteRepo("local-nexus", System.getProperty("nexus-repo"), "default")
           .resolve("org.javaee7.sample:javaee7-simple-sample:war:"
              + System.getProperty("javaee7-sample-app-version"))
           .withoutTransitivity()
           .asSingle(WebArchive.class);
    Running the smoke tests will show the results as:
    Running org.javaee7.sample.PersonResourceSmokeTest
    Feb 25, 2015 2:00:39 PM org.xnio.Xnio <clinit>
    INFO: XNIO version 3.2.0.Beta4
    Feb 25, 2015 2:00:39 PM org.xnio.nio.NioXnio <clinit>
    INFO: XNIO NIO Implementation Version 3.2.0.Beta4
    Feb 25, 2015 2:00:40 PM org.jboss.remoting3.EndpointImpl <clinit>
    INFO: JBoss Remoting version (unknown)
    Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.895 sec - in org.javaee7.sample.PersonResourceSmokeTest
    
    Results :
    
    Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
  5. Run the full tests as:
    mvn test -P fulltest
    This will run all files included in your test suite and will show the results as:
    Running org.javaee7.sample.PersonResourceSmokeTest
    Feb 25, 2015 2:35:38 PM org.xnio.Xnio <clinit>
    INFO: XNIO version 3.2.0.Beta4
    Feb 25, 2015 2:35:38 PM org.xnio.nio.NioXnio <clinit>
    INFO: XNIO NIO Implementation Version 3.2.0.Beta4
    Feb 25, 2015 2:35:38 PM org.jboss.remoting3.EndpointImpl <clinit>
    INFO: JBoss Remoting version (unknown)
    Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.388 sec - in org.javaee7.sample.PersonResourceSmokeTest
    Running org.javaee7.sample.PersonResourceTest
    Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.265 sec - in org.javaee7.sample.PersonResourceTest
    
    Results :
    
    Tests run: 4, Failures: 0, Errors: 0, Skipped: 0
    In both cases, smoke tests and full tests are using the binary that is deployed to Nexus.
Continuous Integration/Deployment Testing Nexus (standard) Repository (version control) Java EE application Release (computing) Test suite Java (programming language) Web Protocols Spring Framework

Published at DZone with permission of Arun Gupta, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • DDD and Spring Boot Multi-Module Maven Project
  • Keep Your Application Secrets Secret
  • Aggregating REST APIs Calls Using Apache Camel
  • How to Activate New User Accounts by Email

Partner Resources

×

Comments
Oops! Something Went Wrong

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends:

Likes
There are no likes...yet! 👀
Be the first to like this post!
It looks like you're not logged in.
Sign in to see who liked this post!