What is Continuous Integration? A detailed explanation!

Continuous Integration is a Good Configuration Management Practice.

Developing software requires planning for change, continuously observing the results, and incrementally course-correcting based on the results. This is how Continuous Integration operates. Continuous Integration is the embodiment of tactics that gives us, as software developers, the ability to make changes in our code, knowing that if we break software, we’ll receive immediate feedback. This immediate feedback gives us time to course-correct and adjust to change more rapidly.
Continuous Integration (CI) is about the fundamentals. It may not be the most glamorous activity in software development, but integrating software is vitally important in today’s complex projects.

Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early.

By integrating regularly, you can detect errors quickly, and locate them more easily.

Continuous Integration doesn’t get rid of bugs, but it does make them dramatically easier to find and remove.

Martin Fowler, Chief Scientist, ThoughtWorks

Continuous Integration and Delivery is one of the recommended practices in DevOps. Continuous Integration has 9 C’s.

• Continuous Learning
• Continuous build
• Continuous unit testing
• Continuous inspection
• Continuous packaging
• Continuous pre-prod deployment
• Continuous testing
• Continuous coverage
• Continuous Approval

Because you’re integrating so frequently, there is significantly less back-tracking to discover where things went wrong, so you can spend more time building features.

Continuous Integration is cheap. Not continuously integrating is costly. If you don’t follow a continuous approach, you’ll have longer periods between integrations. This makes it exponentially more difficult to find and fix problems. Such integration problems can easily knock a project off-schedule, or cause it to fail altogether.

To drill down into the practices of CI a bit more, we need to understand the benefits of CI practices to the team. The top benefits are to provide fast feed back to the members of the team and to ensure any new changes don’t break the working branch. By having fast results – less than 5 min – team members can fix small mistakes that are made during any development process.
One example of this was when I worked with a global team (located in the United States, India, and Ireland). I was able to see firsthand how large of an impact a simple broken build can cause.

A developer in the U.S. checked in the code at the end of the day as they completed a task. The CI build kicked off and took over 30 to 45 min to complete (this was due to a number of problems that I will not go into). The developer leaves to go home, to make it in time to pick the kids up from soccer practice, and is unaware that their code change did not integrate with the other daily changes. Yes, it worked on their machine, but the local changes broke the build when integrated with the latest changes.

As the other teams started their day, they needed to spend extra time to fix the issue, move around the broken build, or (what I’ve seen) ignored the problem and passed it along to the next team. The India and Ireland team members mutter, “if the U.S. broke it, then they need to fix it,” which causes the “us vs. them” dynamic within teams.

If the CI build had been fast, then the developer would have received the feedback sooner and fixed the small change before they left. The next team would have been able to start the day with a clean build and baseline – avoiding frustration, delays, and hidden problems.

Advantage of Continuous Integration

As software is rapidly taking over the economy and transforming business, protected silos of development and the old way of doing things won’t work. In this new dynamic and agile reality, companies must move to a mindset that IT is not a “remote department” that gets to implement what the business needs, in bursts, but instead an integral part of the business itself where development teams are operating in a constant feedback loop with customers.

Continuous integration allows you to deliver new software (meaning: business value) and improve existing software faster, with lower risk. Reducing risk is important, but the processes that underpin continuous integration translate into even more important values to the business:

1. Reduce risks
2. Reduce repetitive manual processes
3. Generate deployable software at any time and at any place
4. Enable better project visibility
5. Establish greater confidence in the software product from the development team
6. CI as a Centerpiece for Quality

1. Reduce Risks

By integrating many times a day, you can reduce risks on your project. Doing so facilitates the detection of defects, the measurement of software health, and a reduction of assumptions.

Defects are detected and fixed sooner—Because CI integrates and runs tests and inspections several times a day, there is a greater chance that defects are discovered when they are introduced (i.e., when the code is checked into the version control repository) instead of during late-cycle testing.

Health of software is measurable—By incorporating continuous testing and inspection into the automated integration process, the software product’s health attributes, such as complexity, can be tracked over time.

Reduce assumptions—By rebuilding and testing software in a clean environment using the same process and scripts on a continual basis, you can reduce assumptions (e.g., whether you are accounting for third-party libraries or environment variables).

The following are some of the risks that CI helps to mitigate. We discuss these and other risks in the next chapter.

• Lack of cohesive, deployable software
• Late defect discovery
• Low-quality software
• Lack of project visibility

2. Reduce Repetitive Processes

Reducing repetitive processes saves time, costs, and effort. This sounds straightforward, doesn’t it? These repetitive processes can occur across all project activities, including code compilation, database integration, testing, inspection, deployment, and feedback. By
automating CI, you have a greater ability to ensure all of the following.

• The process runs the same way every time.
• An ordered process is followed. For example, you may run inspections (static analysis) before you run tests—in your build scripts.
• The processes will run every time a commit occurs in the version control repository.
• This facilitates
• The reduction of labor on repetitive processes, freeing people to do more thought-provoking, higher-value work
• The capability to overcome resistance (from other team members)to implement improvements by using automated mechanisms for important processes such as testing and database integration

3. Generate Deployable Software

CI can enable you to release deployable software at any point in time. From an outside perspective, this is the most obvious benefit of CI. We could talk endlessly about improved software quality and reduced risks, but deployable software is the most tangible asset to “outsiders” such as clients or users. The importance of this point cannot be overstated.

With CI, you make small changes to the source code and integrate these changes with the rest of the code base on a regular basis. If there are any problems, the project members are informed and the fixes are applied to the software immediately. Projects that do not embrace this practice may wait until immediately prior to delivery to integrate and test the software. This can delay a release, delay or prevent fixing certain defects, cause new defects as you rush to complete, and can ultimately spell the end of the project.

4. Enable Better Project Visibility

CI provides the ability to notice trends and make effective decisions, and it helps provide the courage to innovate new improvements. Projects suffer when there is no real or recent data to support decisions, so everyone offers their best guesses. Typically, project members
collect this information manually, making the effort burdensome and untimely. The result is that often the information is never gathered. CI has the following positive effects.

• Effective decisions—A CI system can provide just-in-time information on the recent build status and quality metrics. Some CI systems can also show defect rates and feature completion statuses.
• Noticing trends—Since integrations occur frequently with a CI system, the ability to notice trends in build success or failure, overall quality, and other pertinent project information becomes possible.

5. Establish Greater Product Confidence

Overall, effective application of CI practices can provide greater confidence in producing a software product. With every build, your team knows that tests are run against the software to verify behavior, that project coding and design standards are met, and that the result is a functionally testable product.

Without frequent integrations, some teams may feel stifled because they don’t know the impacts of their code changes. Since a CI system can inform you when something goes wrong, developers and other team members have more confidence in making changes.

Because CI encourages a single-source point from which all software assets are built, there is greater confidence in its accuracy.

6. CI as a Centerpiece for Quality

Some see CI as a process of simply putting software components together. We see CI as the centerpiece of software development, as it ensures the health of software through running a build with every change. Determining the quality of software can be as easy as checking the latest integration build.

Disadvantage of Continuous Integration

If CI has so many benefits, then what would prevent a development team from continuously integrating software on its projects? Often, it is a combination of concerns.

1. Increased overhead in maintaining the CI system—This is usually a misguided perception, because the need to integrate, test, inspect, and deploy exists regardless of whether you are using CI. Managing a robust CI system is better than managing manual processes. Manage the CI system or be controlled by the manual processes. Ironically, complicated multiplatform projects are the ones that need CI the most, yet these projects often resist the practice as being “too much extra work.”
2. Too much change—Some may feel there are too many processes that need to change to achieve CI for their legacy project. An incremental approach to CI is most effective; first add builds and tests with a lower occurrence (for example, a daily build), then increase the frequency as everyone gets comfortable with the results.
3. Too many failed builds—Typically, this occurs when developers are not performing a private build prior to committing their code to the version control repository. It could be that a developer forgot to check in a file or had some failed tests. Rapid response is imperative when using CI because of the frequency of changes.
4. Additional hardware/software costs—To effectively use CI, a separate integration machine should be acquired, which is a nominal expense when compared to the more expensive costs of finding problems later in the development lifecycle.
5. Developers should be performing these activities—Sometimes management feels like CI is just duplicating the activities that developers should be performing anyway. Yes, developers should be performing some of these activities, but they need to perform them more effectively and reliably in a separate environment.Leveraging automated tools can improve the efficiency and frequency of these activities. Additionally, it ensures that these activities are performed in a clean environment, which willreduce assumptions and lead to better decision making.

Types of Continuous Integration

There can be two types of Continuous Integration build

• Build Before Commit
• Personal Build aka Private build
• Sandbox Build
• Build on Every Commit
• Branch SCM Build
• Integration Build aka nightly build

Flow of Continuous Integration using Private Build or Personal Build Approach

Principles and Practice of Continuous Integration

Continuous Integration is backed by several important principles and practices.

The 10 Key Principles of Continuous Integration: Ranked in Order of Priority

Each of the 10 principles complements one another, but there are some that take precedence when you are facing different project factors, including size and budget. Here they are, explained and ranked in priority. The principles are ordered from most to least beneficial for a typical project.

Revision Control
Revision Control has been the basic standard for software development teams for the last couple of decades. The purpose of revision control (also known as version control or source control) is to manage changes made to the files that make up the code for your software project, no matter whether it is a product, website or any application. Revision control allows you switch back and forth between different versions of code using a single command, provided the changes were committed. This replaces the “messy process” sans revision control: countless folders with various versions of code files from different dates. However, when you employ this outdated approach to code management, you lose the ability to have multiple people work on an item and then later merge the work together.
In short, Revision Control not only makes your code base manageable when dealing with making/moving between changes, it also makes it much easier for your developers to integrate their code. This is the root of Continuous Integration; it is the best investment (though most version control systems are free) that you can make on behalf of your developers for your business.
Revision Control allows you to easily do things like Build Automation as well.

Build Automation
Build Automation refers to the ability to either automatically trigger and/or build a clean version of your product, application or website via a single command or action from raw components. Many teams now take this further and allow their systems to be built solely from the code that is obtained from their version control. Build Automation can reduce a 30-minute task to several seconds. Establishing the patterns that your developers perform to start a clean or new system (whether this be a production, staging or development build) will save you time in the long term.
Build Automation does come with risk. There are times when the process for building must change – affecting the way your application is built. Identifying your product’s building process can be a time investment that will front load the development costs. But in the end, the efficiency and ability to get new employees up and going quickly with an environment is well worth it, particularly in bigger teams and shops.
Build Automation allows you to automate the deployment of your product application as well.

Automated Deployment
Automated Deployment is the process of consistently pushing a product to various environments on a “trigger.” It enables you to quickly learn what to expect every time you deploy an environment with much faster results. This combined with Build Automation can save development teams a significant amount of hours.

Automated Deployment saves clients from being extensively offline during development and allows developers to build while “touching” fewer of a clients’ systems. With an automated system, human error is prevented. In the event of human error, developers are able to catch it before live deployment – saving time and headache.

You can even automate the contingency plan and make the site rollback to a working or previous state as if nothing ever happened. Clearly, this automated feature is super valuable in allowing applications and sites to continue during fixes. Additionally, contingency plans can be version-controlled, improved and even self-tested.

Self-Testing Builds
Testing can happen in many different ways using methods you have probably heard thrown around as buzzwords. Some of these involve automated testing like unit testing and interface testing. Self-Testing Builds are the next step. Once you have tests that can be automated, executing them simultaneously with a build is usually not too much more work. Your team will have more awareness on what is going on with your product. Obviously, the more you test (and the more good tests you have) the greater visibility you have into the state of your product before release. This could possibly be the difference between being a reactive or proactive company. Remember: testing is only as good as the environment in which you test it.

Testing in a Clone of Production
Making it a point to minimize the variables in which you are testing is just good planning. Every developer has that story of burning the proverbial midnight oil because their perfect build didn’t work on the production environment like it did on the staging or development environments. Making sure your testing environment is as close to production as possible allows you to minimize this risk.
There are several options for configuration management when it comes to building server machines that allow you to manipulate the configuration of several machines with a single versioned file. This allows developers to see exactly what changes were made and when and by whom they were made – this increases accountability and efficiency. Note: for best results, make sure your developers frequently commit their changes.

Frequent Commits
Committing is the act of creating a new version in a revision control system. Committing marks a point in the history of the code base where you are able to switch over to that point and use the changes made. Frequently, this isn’t just when a new release of the product is made. In fact, each release of your product may be made of thousands of commits – thousands of points in time where you could go back to the state of the code base as it was in that moment. This is a good thing; the more modular the commits, the easier it is for developers to merge, move, add and remove changes with other developers’ work. It also gives them a point of comfort, because if something does go wrong, they can start back where they were the last time they committed work. Making this a frequent occurrence ensures that at the end of the day, everyone’s code can be updated with the latest changes – making code consolidation easy.

Code Consolidation
Code Consolidation is typically best at the end of the day; this is the point when all development features are compiled and merged. Not everyone follows this methodology; some prefer to merge only full complete features, however, Code Consolidation can be quite useful.
First, developers spend less time trying to merge their changes with one another. Although this process is usually automatic, there is a case in which one developer’s changes may conflict with another developer’s changes. This happens when both developers end up changing the exact same line of code. Catching these early while it’s still fresh on their minds will increase efficiency.
Secondly, if you established Automated Building on a test server and those builds are Self-Testing Builds, you will be able to track the performance of your product throughout production. Keep in mind, as code changes, tests need to change as well.
Lastly, it gives your other developers visibility on code that another developer is writing. This enacts a system of checks and balances, particularly if you have set up a code review process for every merge that is made into the main development branch. You can correct problems earlier and improve the quality of your code, ultimately leading to a better product.

Fast Builds
Time is money. Fast Builds give you that time. You don’t want to pay your developers for watching Youtube every time they have to build a new environment. Additionally, depending on the trigger that is set up for an automated build made for testing, a build can take so long that the trigger fires more than once before an actual environment is completely built. This is bad if it happens on a daily basis. There are times where this will happen anyway if your trigger is something like “on every merge to the development branch,” and it’s close to a major deadline. Fast Builds allow developers to get on their feet faster, receive test results faster and see your product faster.

Build Availability
It is important to have a current development and staging build available at all times. Regardless of your Automated Testing, there are some things a computer cannot detect or it makes very little sense to try and make it do so. In these cases manual testing is required.
Additionally, you can provide a public (or pseudo-public) version of your build to your clients. Everyone loves a sneak peek into the new great features that are coming along – availability is key.

Test Result Availability
Who determines what tests passed and what tests failed? Test Result Availability gives visibility on the results to developers, managers and client stakeholders. This principle supports the continued system of checks and balances. There are many test management products that show the test results in a comprehensive graph of passes and fails. Typically, these products let you drill down into the results for in depth analysis. A reconciliation of each test error each day can be performed so everyone knows exactly why it failed and when it will be fixed.
Like Build Availability, allowing your clients to see test results can be assuring. It is important to note that you should only show them results on the builds that you show them. For instance, if you have a staging environment that is only built at every stable development cycle, then show them tests related to that build. This gives your clients confidence in your ability and your devotion to quality.

Final Thoughts

When you are getting your business started with Continuous Integration, remember you are doing three important things:

• Improving the quality of your code. You can achieve a better quality product application or website project.
• Making your developers more efficient. You can receive “more bang for your buck” and narrow down the cost of software projects.
• Showing your prowess in your market. You let everyone know that you have the best practices that produce the highest quality work.

Practice of Continuous Integration

There are some of the best Practices of implementing CI for any project which will make Quality and Feedback mechanism more robust.

• Maintain a single source repository
• Automate the build
• Make your build self-testing
• Every commit should build on an integration machine
• 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
• Automate deployment
• Commit code frequently – Commit code to your version control repository at least once a day.
• Don’t commit broken code – Don’t commit code that does not compile with other code or fails a test.
• Fix broken builds immediately – Although it’s the team’s responsibility, the developer who recently committed code must be involved in fixing the failed build.
• Write automated developer tests – Verify that your software works using automated developer tests. Run these tests with your automatedbuild and run them often with CI.
• All tests and inspections must pass – Not 90% or 95% of tests, but all tests must pass prior to committing code to the version control repository.
• Run private builds – To prevent integration failures, get changes from other developers by getting the latest changes from the repository and run a full integration build locally, known as a private system build.
• Avoid getting broken code – If the build has failed, you will lose time if you get code from the repository. Wait for the change or help the developer(s) fix the build failure and then get the latest code.

Continuous Integration Checklist

• On average, is everyone on your team committing code at least once a day? Are you employing techniques to make it easier to commit code often?
• What percentage of each day’s integration builds is successful (that is, the most recent build run has passed)?
• Is everyone on your team running a private build before committing to the repository so that integration errors are reduced?
• Have you scripted your builds to fail if any of your tests or inspections fail?
• Is a broken integration build a priority to fix on your projects?
• Do you avoid getting the latest code from the version control systemwhen there is a broken build?
• How often do you consider adding automated processes to yourbuild and CI system—on a continuous or even periodic basis?

Continuous Integration is NOT

CI is not just the process of gathering a few scripts together and running them all the time. In the preceding scenario, it’s great that Joan wrote those automation scripts, but in order for them to actually add value to the end product, they must be added to the version control repository and made a working part of the build process. Figure 2-2 illustrates the steps to making a process continuous.

How to start the Continuous Integration for any project?

These steps can be applied one by one to virtually every activity you conduct on a project.

• Identify – Identify a process that requires automation. The process may be in the areas of compilation, test, inspection, deployment, database integration, and so on.
• Build – Creating a build script makes the automation repeatable and consistent. Build scripts can be constructed in NAnt for the .NET platform, Ant for the Java platform, and Rake for Ruby, just to name a few.
• Share – By using a version control system such as Subversion you make it possible for others to use these scripts/programs.Now the value is being spread consistently across the project.
• Make it continuous – Ensure that the automated process is run with every change applied, using a CI server. If your team has the discipline, you can also choose to manually run the build with every change applied to the version control system.

Here is an acrostic to help you remember and communicate this:

“I Build So Consistently”—for Identify, Build, Share, and Continuous.

Is It Continuous Compilation or Continuous Integration?

I’ve worked with a number of organizations on implementing CI, and on several occasions I’ve heard the reply, “Yes, we do CI.” Of course, I think, “Great!” and then ask a few questions.

• How much code coverage do you have with your tests?
• How long does it take to run your builds?
• What is your average code complexity?
• How much code duplication do you have?
• Are you labeling your builds in your version control repository?
• Where do you store your deployed software?

I discover that what they’ve been doing all along is more like a “continuous compilation,” in which they’ve set up a tool like Cruise- Control to poll their version control repository (e.g., CVS) for changes. When it detects changes, it retrieves the source code from CVS, compiles the code, and sends an e-mail if anything goes wrong. Automatically compiling the software system on a separate machine is better than nothing at all, but doing that isn’t going to provide all of the benefits of a full-featured CI system.

How to motivate team or project to Implement CIs?

CI is not just a technical implementation; it is also an organizational and cultural implementation. People often resist change, and the best approach for an organization may be to add these automated mechanisms to the process piece by piece.

At first the build can just compile the source code and package the binaries without executing the automated regression tests. This can be effective, initially, if the developers are unfamiliar with an automated testing tool. Once this is in place and developers have learned the testing tool, you can move closer to the benefits of CI: running these tests(and inspections) with every change.

When you are planning out multiple projects and have more complex projects on the horizon, take advantage of your smaller projects to start implementing CI and cut your teeth on them. If your development team or vendor is not familiar with CI, then bring on some extra help to get them introduced and skilled up with CI. Use the consulting help to get your team started on the small project and then be there to assist them on the big project.

When to implement CIs for a project?

While there is no “one size fits all” answer, here are some examples of types of projects where CI is key and often critical:

• Integration costs time
• Integration money?
• Last moment delay in Release?
• Quality of Code is coming as bug in last release
• Halting the further development due to code freeze and integration
• You are “going commando” without source code management for your site and deployment process. No tracking. No rollback.
• You are deploying manually between environments. It’s slow. It’s brittle. It’s painful.
• You are stuck in a “hot mess” of hotfixes. Not uncovering problems early. Forced into making changes late in the game.
• You are editing CMS configurations manually. And doing it on Staging or Production environments! (Everyone who has ever worked on a Drupal project ever knows this one.)
• You hear the all too common “it works on my machine” uttered by your developers. But then it breaks on Staging and Production. Now pair this with manual deployments… not fun.
• You do not have automated site builds or automated tests in place. Proper QA is painful or even non-existent.
• If you have multiple developers on your team, especially ones that may be changing over time.
• If your site is being developed by a distributed team, especially geographically spread out across different time zones.
• If your project includes integration with other systems.
• If you are handling transactions in your site.
• If you are treating your site like a product where you are regularly gathering feedback and releasing features over the lifecycle of the site.

Cost Vs Continuous Integration

Doesn’t Continuous Integration cost a lot to do? Can’t we just skip doing it?

Let’s go back to one of the common themes for CI. The earlier you get feedback, the earlier you identify problems and the less costly they are to fix. Say you skip implementing CI practices for your project and live with some of the red flag issues I referenced earlier. Are you really saving money in your project that way? Those issues tend to fester and compound themselves as a project goes, and they get even more pronounced after you launch your site and have to live with it for the long haul.

Problems that you missed early in your project and patched over with fixes late in the game have a tendency to cost serious dollars later during support and during upgrades.

There is often a very sharp rise in relative costs for fixing defects at the later stages.

A common misconception is simply to think of CI as overhead in a web project, and expensive overhead at that.
First, is it really all that costly to implement some basic CI practices into your development process? No, not really. Let’s take a look at a pretty typical example CI workflow with Drupal.

• Your developers commit some code to a repository (e.g. in Git)
• They push that code up
• The update to the repository triggers a job on your CI server (e.g. on Jenkins)
• The job kicks off code deployment automatically
• It runs Drush commands to update the database and revert Features
• It runs some tests on the site build (e.g. automated unit, smoke, functional, regression, acceptance tests)
• You get a status report back from your CI server (e.g. pass/fail)

Approach to implement Continuous Integration

• Developers check out code into their private workspaces.
• When done, the commit changes to the repository.
• The CI server monitors the repository and checks out changes when they occur.
• The CI server builds the system and runs unit and integration tests.
• The CI server releases deployable artefacts for testing.
• The CI server assigns a build label to the version of the code it just built.
• The CI server informs the team of the successful build.
• If the build or tests fail, the CI server alerts the team.
• The team fix the issue at the earliest opportunity.
• Continue to continually integrate and test throughout the project.

Continuous Integration brings multiple benefits to your organization and Business:

• Say goodbye to long and tense integrations
• Increase visibility which enables greater communication
• Catch issues fast and nip them in the bud
• Spend less time debugging and more time adding features
• Proceed in the confidence you’re building on a solid foundation
• Stop waiting to find out if your code’s going to work
• Reduce integration problems allowing you to deliver software more rapidly

In business terms, the value of Continuous Integration is:

• Reducing risk
• Reducing overheads across the development & deployment process
• Enhancing the reputation of the company by providing Quality Assurance

Benefits of Continuous Integration for Dev?

The benefit is that you know – immediately – when someone has broken the build. This means either

A) They committed code that prevents compilation, which would screw any one up who did an ‘update’, or
B) They committed code that broke some tests, which either means they introduced a bug that needs to be fixed, or the tests need to be updated to reflect the change in the code.

If you are a solo developer, CI isn’t quite as useful if you are in a good habit of running your tests before a commit, which is what you should be doing. That being said, you could develop a bad habit of letting the CI do your tests for you.

As a solo programmer, it mainly comes down to discipline. Using CI is a useful skill to have, but you want to avoid developing any bad habits that wouldn’t translate to a team environment.

The truth is, that continuous integration makes most sense in teams. Single developers can also get some advantages, you must decide yourself if they are enough to counter the time you invest into setting a CI-system up.
If you forgot to checkin some needed file, the repository contains a broken version, even if it works on your machine. CI would detect that case.

If your CI-server runs on a different machine, it can indicate dependencies on your build-environment. Means, the build and all tests can work on your dev-box, but on another machine some dependencies aren’t fulfilled and the build breaks.
Daily builds can indicate, that your older software doesn’t work with the newest upgrade of the OS/compiler/library…
If your CI-system has an archive of build-artifacts you can easy get an distribution of an older version of your software.
Some CI have a nice interface to show you metrics about your build, have links to automatic generated documentation and stuff like that.

We use our CI system to do Release builds (as well as the usual automatic “on-commit” builds). Being able to click a button that kicks off a Release build that steps through all the processes to release a setup is:
fast (I can go straight on with other things, and it runs on a separate machine so it is not slowing me down);
repetitive (it doesn’t forget anything, including copying the setup to the release folder and notifying everyone who needs to know) dependable (no mistakes, unlike a human!).

Benefits of Continuous Integration for QA?

• Early detection of bugs
• Early detection of integration issues
• Early detection of failed unit tests / self testing code
• Automate deployment
• Public shame towards anyone who breaks the trunk

Before Continuous Integration

With Continuous Integration

Elements of Continuous Integration & Delivery

• Continuous Learning
• Continuous build
• Continuous unit testing
• Continuous inspection
• Continuous packaging
• Continuous pre-prod deployment
• Continuous testing
• Continuous coverage
• Continuous Approval

• Author
• Recent Posts

Follow me

Rajesh Kumar

Mentor for DevOps - DevSecOps - SRE - Cloud - Container & Micorservices at Software AG

Join my following certification courses...
- DevOps Certified Professionals (DCP)
- Site Reliability Engineering Certified Professionals (SRECP)
- Master in DevOps Engineering (MDE)
- DevSecOps Certified Professionals (DSOCP)
URL - https://www.devopsschool.com/certification/

My Linkedin - https://www.linkedin.com/in/rajeshkumarin

Follow me

Latest posts by Rajesh Kumar (see all)

• What is Mobile Virtual Network Operator? - April 18, 2024
• What is Solr? - April 17, 2024
• Difference between UBUNTU and UBUNTU PRO - April 17, 2024