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
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
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
Partner Zones AWS Cloud
by AWS Developer Relations
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
Partner Zones
AWS Cloud
by AWS Developer Relations
Securing Your Software Supply Chain with JFrog and Azure
Register Today

Trending

  • Integrate Cucumber in Playwright With Java
  • Five Java Books Beginners and Professionals Should Read
  • Step Into Serverless Computing
  • Turbocharge Ab Initio ETL Pipelines: Simple Tweaks for Maximum Performance Boost

Trending

  • Integrate Cucumber in Playwright With Java
  • Five Java Books Beginners and Professionals Should Read
  • Step Into Serverless Computing
  • Turbocharge Ab Initio ETL Pipelines: Simple Tweaks for Maximum Performance Boost
  1. DZone
  2. Testing, Deployment, and Maintenance
  3. Deployment
  4. Continuous Integration: Why You Don't Really "Get It"

Continuous Integration: Why You Don't Really "Get It"

Mitch Pronschinske user avatar by
Mitch Pronschinske
·
Sep. 28, 11 · News
Like (0)
Save
Tweet
Share
15.78K Views

Join the DZone community and get the full member experience.

Join For Free

A vast majority of daily practitioners of Continuous Integration don't really understand it. This is a bold statement, I know. But it is not made to simply capture attention. Most practitioners of Continuous Integration, when asked, will either tell you that CI is about integrating changes often, or that it's about producing frequent builds of your software. Both these answers are incomplete at best. Even articles on Continuous Integration gloss over the thinking behind it and jump straight to the implementation.

 

This is a guest post from UrbanCode's CEO Maciej Zawadzki


So this blog entry is about the "thinking" behind Continuous Integration. Because only by understanding the core ideas behind CI can you understand what is happening in the industry now or get a glimpse of where it is headed in the future. Once you "get" the core concepts behind CI, it's easy to see that Continuous Delivery is a natural extension of Continuous Integration.

Most people know that CI is based on the observation that the longer development streams diverge -- the longer developers work independently without synching their work -- the more painful the eventual integration will be. Taking the converse of the above statement, the more frequently developers integrate their changes, the more painless those integrations will be. Thus, lets integrate as frequently as possible, continuously, on every change. Hopefully, this is nothing new. Now notice that this is not enough to understand Continuous Integration as it leads to the following question.

Why does it not suffice for developers to simply check-in or commit their changes frequently to practice CI? This question indicates that there is one additional, although rarely stated, aspect to CI -- that in order for a merged change to be successfully "integrated," it should not degrade the code quality. This implied condition -- that each integration will not decrease the code quality -- is the key to understanding CI; the rest is implementation details. It is this condition that shapes the practice of Continuous Integration and gets the ball rolling towards Continuous Delivery.

The familiar implementation of Continuous Integration using a build and test process can be derived from our now explicitly stated condition (that each integration not decrease the code quality). Notice that this condition requires that we be able to determine the quality of code in order to implement CI -- how else would we know whether the quality decreased? And how do we determine the quality of a code base? We test it. And how do we test it? We compile (build) the code and run tests against it. This is why Continuous Integration is implemented as a build and test process.

The fast feedback required by CI necessitates a compromise that leaves a lot of unfulfilled value on the table. It is well known that CI requires fast feedback -- ideally we get feedback on one change before we start integrating the next change. The determination of quality, on the other hand, is one of those crazy things where the more tests we run, the more accurate our picture of the code quality will be. But tests take time, thus creating the need for a compromise. Most implementations of CI compromise by including only some of the tests (typically unit tests) in the build and test process. And this limits CI to having only a partial view of the code quality and leaves a more complete picture of code quality undelivered.

In order to provide a more complete picture of code quality, we need to run more tests. At least for web applications, more tests means in-container tests, and that means deployment to a container. Thus, if we want to provide a more accurate picture of code quality, as our explicitly stated condition suggests, we need to start deploying our code to test environments and run progressively more tests. What shall we call this practice? How about Continuous Delivery.

The purpose of this blog entry was to make explicit that little implied condition in CI -- that the integration must not decrease the quality of the code base. We've demonstrated how this condition can be used to derive the typical implementation of CI (the build and test loop) and Continuous Delivery. Can you spot other industry trends that can be traced back to our non decreasing code quality condition?

Continuous Integration/Deployment Integration Testing IT

Published at DZone with permission of . See the original article here.

Opinions expressed by DZone contributors are their own.

Trending

  • Integrate Cucumber in Playwright With Java
  • Five Java Books Beginners and Professionals Should Read
  • Step Into Serverless Computing
  • Turbocharge Ab Initio ETL Pipelines: Simple Tweaks for Maximum Performance Boost

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

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

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com

Let's be friends: