Continuous Integration (CI)

Continuous Integration (yellow). Credit: Devops
  • the key steps involved in creating quality software
  • the practices and types of tools that are used to accelerate these steps, focusing on their roles rather than specific brands (think ‘Source Code Repository’ over ‘GitHub’, ‘Automation Server’ over ‘Jenkins’), leaving me to select which tool suits me.
  • a high level software architecture and process flow that achieves ‘Continuous Integration’.


  • Continuous Integration (CI)
  • Continuous Delivery (CD)

Continuous Integration

A. Source Code Management Tool

  • stores source code
  • allows developers access to copy the current version to their own computers (incl. permission management, remote access across different offices)
  • allows developers to create ‘branches’ of the code, where they can work on changes without affecting the core version
  • gives tools for colleagues to review a developers changes in a branch and to comment on or approve them
  • allows changes to be merged back in to the original code, including tools for identifying and resolving conflicts where two simultaneous changes have made differing change to the same code
  • tracks all changes made to the codebase

B. Build Tool

  • Third party software libraries (Software 101: don’t re-invent the wheel! if someone’s already written something doing what you need, re-use it!)
  • Other ‘binary files’ e.g. the image of your company logo for the loading screen of your mobile app.

C. Binary Repository Manager

Unit tests

  • A failing test always indicates that the code in that unit is not doing what it should.
  • Succeeding test sets do little to confirm that the application as a whole performs as expected.

Integration tests

  • A failing integration test could either be down to code, or down to environmental issues.
  • Successful integration test sets gives confidence to the business that the overall application behaves as it should.
Credit: Testing Types

D. Automated Test Execution Engine(s) for Unit and Integration Tests

When should Unit and Integration tests be run?

  • by developers regularly during their development process
  • by developers immediately before a code commit
  • as part of the build process for every build, being upon, or soon after every commit.
  • by developers before a major commit involving many components or side effects
  • as part of a periodic ‘integration’ build e.g. every 24 hours.
  • as part of builds that will be released

E. Code Quality Manager

F. Automation Server

  • Notification received from an external system. E.g. Automation servers support integrations with Source Code repositories so that they can be notified of any changes to the code.
  • Scheduled (e.g. every 15 minutes, or daily)
  • Manual launch by a user


  • covering 6 types of tool, providing Open Source examples for each:
    A. Source Code Management Tool
    B. Build Tool
    C. Binary Repository Manager
    D. Test Execution Engine(s) for Unit Testing and Integration Testing
    E. Code Quality Manager
    F. Automation Server
  • describing in a high level software architecture how these tools can be strung together via to create a Continuous Integration process flow

Next Article in the Series

Continuous Delivery (CD)

Other Links





Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

A Tale of an Elastic Kubernetes Service Setup

A cluster of mushrooms growing.

Python GUI — Building a Simple Application with PyQt and Qt Designer

Mapping Story Points With Hours

What types of testing can you perform on your e-commerce website?

Homelab: The Journey Begins

Why Hotkeys are so Hot

Implement custom validators using JSR based validations [Java 8/Spring]

A look at the Dell PowerEdge MD1400 for Post Production.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Graham Wright

Graham Wright


More from Medium

Why Teams Should Care about Developer Experience

Early feedbacks on API integration

Top 7 reasons to adopt micro-services architecture

Part 1: How Service Oriented Architecture Gave Birth to DevOps