<p>Continuous Testing is an important part of a fast development process. You can detect bugs much faster and find them more easily since the code changes are smaller.
But that's independent from integrating my feature into the product of the main/master branch. I could also test very often on my feature branch and never integrate it. So it is a requirement for Continuous Integration but it's not restricted to only that integration model.</p>
<p>The difference between the two definitions of Continuous Integration is not that big. Both state, that you should integrate your features rapidly or multiple times a day.</p>
<p>If you cut your features into smaller parts, you can also merge them more often into your main/master branch. You should write your code in a non breaking way, to be able to integrate often. The continuous testing helps a lot to ensure, that the changes don't break anything.</p>
<p>The important part of CI is, that you get immediate feedback on your code and that each developer is working with the same code base. So you don't have bigger problems with merging of huge feature branches at the end of the development.
The problem with huge feature branches and late integration is the following: You finish your development and test everything on your feature branch. When you merge it into the main/master branch, the build breaks because there are some changes on main/master that are incompatible with yours. So you need to recode some parts, redo the tests and retry the merge.
This could be prevented, if everyone would be using the latest codebase and all changes are integrated into that codebase continuously.</p>
<p>You can also use trunk based development (<a href="https://trunkbaseddevelopment.com/" rel="nofollow noreferrer">https://trunkbaseddevelopment.com/</a>) as an extreme form of CI. All work is done on the main/master branch, that is called trunk in this model. Extensive automated tests ensure, that your commits don't break anything.</p>
<p>There is no organisation that has the ownership of the concept Continuous Integration, so everyone could publish his or her own definition of it.</p>

CC BY-SA 4.0
2021-11-20T06:19:19.903Z
Thanks, this clears things up. My conclusion is that CI is a silly idea. Lightweight branches are the marvel of the previous decade and the CI model denounce them.
Vorac
CC BY-SA 4.0
2021-11-22T10:52:30.677Z
It's not a silly idea. It's just a different approach. You have lesser errors and can detect them earlier in the development process. But everything depends on the way your teams want to work.
seism0saurus
CC BY-SA 4.0
2021-11-19T08:31:26.797Z
2021-11-19T08:31:26.797Z
seism0saurus
<p>Well, here is a blog that might help you which provides short and clear answer about the use of CI, CT and also CD too.
<a href="https://www.bunnyshell.com/blog/what-is-ci-cd-ct-devops" rel="nofollow noreferrer">https://www.bunnyshell.com/blog/what-is-ci-cd-ct-devops</a></p>

CC BY-SA 4.0
2021-11-21T06:09:15.493Z
2021-11-21T06:09:15.493Z
AV Reddy
<p>We can use CT as a small part of the big box we call CI.</p>
<p>Nothing will change the fact that it's all part of an accepted general concept called CI and within that CI, you can wrap all the steps you need, as long as you don't forget that <strong>the main goal is the automatic integration of all the new code to the codebase</strong>.</p>
<p>You define and automate what is required for a new code to integrate the codebase. And if in your case that requires automated testing, then CT is part of your CI.</p>
<p>If your project only requires formatting standards, for example, then you have a CI process that doesn't have CT steps.</p>
<p>If the goal was just to test the code, then we would only test the new code. The rest of the code is already tested, right? So why bother?</p>
<p>We bother because we know that one line of code in the wrong place can implode a project, so we test the whole thing. We are not testing the new code, we are testing to ensure that the new code plays nice with the rest of the codebase.</p>
<p>So the main thing is not the testing, is the integration, the testing is just a tool we use to get there.</p>

CC BY-SA 4.0
2021-11-20T06:12:19.043Z
Thanks, this clarifies things a bit. What remains unclear to me is the precise meaning of the bolded statement. What do you mean "automatic"? What do you mean by "all"? How often is that supposed to happen?
Vorac
CC BY-SA 4.0
2021-11-19T09:39:26.923Z
2021-11-19T09:39:26.923Z
Magus
<p><a href="https://en.wikipedia.org/wiki/Continuous_integration" rel="nofollow noreferrer">Wikipedia</a> insists that</p>
<blockquote>
<p>(CI) is the practice of merging all developers' working copies to a shared mainline several times a day</p>
</blockquote>
<p>which sounds to me like &quot;branches are prohibited&quot; which makes no sense. I am a huge proponent of the rebase workflow on master but would never insist it scales well - that's what feature branches are for.</p>
<p><a href="https://www.atlassian.com/continuous-delivery/continuous-integration" rel="nofollow noreferrer">Atlassian</a> instead states</p>
<blockquote>
<p>[CI] allows software developers to work independently on features in parallel. When they are ready to merge these features into the end product, they can do so independently and rapidly.</p>
</blockquote>
<p>This sounds to me like <a href="https://en.wikipedia.org/wiki/Continuous_testing" rel="nofollow noreferrer">CT</a>. Where's the &quot;integration&quot; part?</p>
<p>The question:</p>
<p>How is CI defined? Who emits the definition? How is it different from CT?</p>

<continuous-integration>
What is CI and how is it different from CT?
Vorac
# What is CI and how is it different from CT?

(Asked by: username_0 on 2021-11-19)

[Wikipedia](https://en.wikipedia.org/wiki/Continuous_integration) insists that

> (CI) is the practice of merging all developers' working copies to a shared mainline several times a day

which sounds to me like "branches are prohibited" which makes no sense. I am a huge proponent of the rebase workflow on master but would never insist it scales well - that's what feature branches are for.

[Atlassian](https://www.atlassian.com/continuous-delivery/continuous-integration) instead states

> [CI] allows software developers to work independently on features in parallel. When they are ready to merge these features into the end product, they can do so independently and rapidly.

This sounds to me like [CT](https://en.wikipedia.org/wiki/Continuous_testing). Where's the "integration" part?

The question:

How is CI defined? Who emits the definition? How is it different from CT?

**Tags:** continuous-integration


---

## 3 answers

### Answer by username_1 on 2021-11-19. Score: 0 | Accepted answer

Continuous Testing is an important part of a fast development process. You can detect bugs much faster and find them more easily since the code changes are smaller.
But that's independent from integrating my feature into the product of the main/master branch. I could also test very often on my feature branch and never integrate it. So it is a requirement for Continuous Integration but it's not restricted to only that integration model.

The difference between the two definitions of Continuous Integration is not that big. Both state, that you should integrate your features rapidly or multiple times a day.

If you cut your features into smaller parts, you can also merge them more often into your main/master branch. You should write your code in a non breaking way, to be able to integrate often. The continuous testing helps a lot to ensure, that the changes don't break anything.

The important part of CI is, that you get immediate feedback on your code and that each developer is working with the same code base. So you don't have bigger problems with merging of huge feature branches at the end of the development.
The problem with huge feature branches and late integration is the following: You finish your development and test everything on your feature branch. When you merge it into the main/master branch, the build breaks because there are some changes on main/master that are incompatible with yours. So you need to recode some parts, redo the tests and retry the merge.
This could be prevented, if everyone would be using the latest codebase and all changes are integrated into that codebase continuously.

You can also use trunk based development (<https://trunkbaseddevelopment.com/>) as an extreme form of CI. All work is done on the main/master branch, that is called trunk in this model. Extensive automated tests ensure, that your commits don't break anything.

There is no organisation that has the ownership of the concept Continuous Integration, so everyone could publish his or her own definition of it.

> **Comments:**
> **username_0**: Thanks, this clears things up. My conclusion is that CI is a silly idea. Lightweight branches are the marvel of the previous decade and the CI model denounce them.  
> **username_1**: It's not a silly idea. It's just a different approach. You have lesser errors and can detect them earlier in the development process. But everything depends on the way your teams want to work.  

---

### Answer by username_2 on 2021-11-21. Score: 0

Well, here is a blog that might help you which provides short and clear answer about the use of CI, CT and also CD too.
<https://www.bunnyshell.com/blog/what-is-ci-cd-ct-devops>


---

### Answer by username_3 on 2021-11-19. Score: 0

We can use CT as a small part of the big box we call CI.

Nothing will change the fact that it's all part of an accepted general concept called CI and within that CI, you can wrap all the steps you need, as long as you don't forget that **the main goal is the automatic integration of all the new code to the codebase**.

You define and automate what is required for a new code to integrate the codebase. And if in your case that requires automated testing, then CT is part of your CI.

If your project only requires formatting standards, for example, then you have a CI process that doesn't have CT steps.

If the goal was just to test the code, then we would only test the new code. The rest of the code is already tested, right? So why bother?

We bother because we know that one line of code in the wrong place can implode a project, so we test the whole thing. We are not testing the new code, we are testing to ensure that the new code plays nice with the rest of the codebase.

So the main thing is not the testing, is the integration, the testing is just a tool we use to get there.

> **Comments:**
> **username_0**: Thanks, this clarifies things a bit. What remains unclear to me is the precise meaning of the bolded statement. What do you mean "automatic"? What do you mean by "all"? How often is that supposed to happen?  

---

