Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly. [Martin Fowler]

"Most significant problems in software development is assuming". The CI reduce that assumptions.


Introduction

The CI comes as a solution to reduce many problems in the development lifecycle. The big deal is put it to reality in the project's real life. It's hard not because require a big knowledge or a super technical challenges. One important point is to change the mindset and change the development routine. The projects achieves that point implies some other points should be in the right direction to ensure a cert of success on that decision. When CI/CD work together with other solutions it brings a great benefits to the final product. However, it's necessary to work in different parts of the process to make it works.

The CI has as benefit, for example, the rapid feedback and the reduction the time when some error is the detected to fix it. It impacts directly when we talk about bugs, one point responsible to destroy confidence and mess up schedules and reputations.

So, CI solve some pain pints: effort consuming, fixes after the interactions, long feedback cycle, long iteration.

The picture bellow ilustrate CI/CD process. The CI corresponds the first part until the build and tests.


Bullet points

Values:

  • Reduce risk: defects are detected and fixed sooner, health of the software is measurable, deruce assumptions.
  • Reduce repetitive manual process: the process runs the same way, same order and after each commit is detected.
  • Generate deployable dostware at any time and at any place: you have a release any time
  • Enable better project visibility: helps to effective decisions, noticing trends.
  • Establish greater confidence in the software product from the development team.

Principals to actieve CI:

  • A single central repository where code lives
  • Developers check-in/commit their code frequently
  • Build should be triggeres everytime a developer checks code
  • Build should be automated and fast
  • Build should compile the code as well as run automated
  • Fixing a failed build should be top priority for developers
  • Build results should always be communicated/visible to all developers

The default CI Cycle:

  1. Developer run the build locally
  2. Commit to version control (daily). It trigger the CI cycle.
  3. CI server detect the changes, retrieve the code from repository and execute build
    • Build: Compilation, testing, inspection. Put the code together and check everything is going right.
    • Integration: compile source code, integrate database, run tests, run inspections (rules to guarantee the quality of code).
  4. All the tests must pass. If the build break it must be fixed.
  5. Generate the product (war, executable, etc)
  6. Generate the feedback reports.
  7. Seek improvements from the reports

Best Practices of Continuous Integration

  • Maintain a Single Source Repository.
  • Automate the Build
  • Make Your Build Self-Testing
  • Everyone Commits To the Mainline Every Day
  • Every Commit Should Build the Mainline on an Integration Machine
  • Fix Broken Builds Immediately
  • Keep the Build Fast
  • Test in a Clone of the Production Environment
  • Make it Easy for Anyone to Get the Latest Executable
  • Everyone can see what’s happening
  • Don’t comment failing Tests
  • Revert if to fix will spend long time

What is not

  • If you spend long time to commit and push to remote repository
  • If you spend long time to do the pull
  • If you storage the code locally for a long time
  • If you do a lot of local commits without pull and push with remote repository, you are not doing integration.


Full-Featured CI System

Continuous Database Integration

Process of rebuilding your database and test data anytime a change is applied to a project's version control repository

Why? Databases should be trustworthy and they are a shared resources.

Pain Direction
Persistent state increases testing complexity (1) Restore/rebuild test databases regularly, (2) Run database tests as transactions
Database tests are time consuming (1) Only run a subset of the tests, (2) Run against a subset of the data, (3) Run against a database mock

Continuous Testing

Continuous testing (CT) is a software development process in which applications are tested continuously throughout the entire software development life cycle (SDLC). The goal of CT is to evaluate software quality across the SDLC, providing critical feedback earlier and enabling higher-quality and faster deliveries. [synopsys]
  • Automate Unit tests (verify behaviour of small elements): "...unit tests are low-level, focusing on a small part of the software system. ... unit tests are expected to be significantly faster than other kinds of tests. ...it can be a bunch of closely related classes or methods". It depends what is the unit for the developer.[Martin F.- Unit Test]
  • Automate Component tests (portion of a system - may require dependencies as database - also called as Integration Test): "determine if independently developed units of software work correctly when they are connected to each other."[Martin F.- Integration Test]
  • Automate System tests (exercise complete software system) - tests webservice endpoints and GUI works end to end as designed. Running in intervals as at night
  • Automate Functional Tests (test funcionality from the viewpoint of the client - tests simulate client - acceptence tests) - use of selenium or cypress, for example
  • Categorize Developer tests: helps to run slower tests after faster tests(e.g run unit tests every deploy and system tests once a week)
  • Write Tests for defects: after find a bug add the test for it.

Continuous Inspection

It is the process to inspect the code and seeking defects. These detect possible bugs in the code by bad quality or missing code review. Some tools with access to the code can do those inspections as part of the build.

It is different from a test because it analyzes the code using some predefined rules.

The criteria used should consider, for instance, functional and structural requirements. Examples of it are the initialization of the application, redundancy in the code, control flow, efficiency, maintenance, number of lines of code, and class-based design complexity measures.

The Continuous Inspection helps to guarantee the code quality, reduce the complexity and duplicate code.

Continuous Feedback

This process is used to inform team about the CI process. If some problems happen the team has to have to notified as soon as posssible to do some action. To be effective the notification has to send the right information to the right people.

However, it's necessary to pay attention about the information overload which can cause the team start to ignore these notifications.

The way to do the feedback depends each project. It can be done using sms, email, slack, windows task bar, sounds, etc.

Videos

References