CODEWITHSUNDEEP
continuous-integration
Tzu ng
Tzu ng

Reputation: 9244

Continuous integration - is it needed?

I have this question to validate my knowledge about continuous integration. Due to what I understand : Continuous integration will help us with checking if the build has the any bugs or errors [ red light ] as fast as possible.

I assume all of our developers know about TDD, they will make the test all the time before pushing something to the server. It meants the pushed code has to be passed before pushing, so do we need the ci server anymore since we always have a green light.

So my question is if we have a good team that always follow the rules of TDD in development, do we need the ci server ?

Upvotes: 2

Views: 339

Answers (3)

Jason Sankey
Jason Sankey

Reputation: 2338

All teams should be doing continuous integration, but this doesn't mean that you need to have a CI service. There is a classic post by James Shore on this:

Continuous Integration is an Attitude, Not a Tool

So if you have the attitude, even without the server, you get the vast benefits of CI. That said, there are numerous reasons a CI server can help:

  1. Humans are fallible, even with the best intentions they don't always get things right. The server is automated and predictable.
  2. The server runs a build on a cleaner environment than the typical developer workstation. This can highlight problems that otherwise go unnoticed until you deploy/ship.
  3. If you support multiple platforms, a good CI server can easily test on them all for you.
  4. If you have a lot of integration tests, which may be slower than unit tests, it can be onerous to require all developers to run them all pre-checkin. Instead they can run fast unit + smoke tests to catch 99% of problems, and let the CI server run the full suite.
  5. Servers can maintain a build history, showing trends over time. This is excellent for drift analysis (checking performance trends), for example.
  6. CI servers provide a lot of added functionality, varying from server to server, that you may be interested in (e.g. support for release builds, flexible scheduling, notifications, parellel builds).

In summary: you don't need a server to get the key benefits of CI. But you can get a lot of related benefits from the right server software.

Upvotes: 4

devdigital
devdigital

Reputation: 34349

It depends what your CI server is doing. You could have every developer run all unit tests locally before committing to the central source code repository, but how would a developer know which unit tests to run? They would have to run all of them, and all integration tests, UI tests etc. This could take a long time with a large number of tests.

Typically a CI server will be configured to run the longer integration tests overnight to see if any breaking changes have been introduced.

Also, another important feature of the CI server that you've overlooked is the actual building of the source code. It's very common to introduce build errors when you commit changes to the source code repository because you've either forgotten to commit a new file, or there are assumptions that your source code is making about the development environment it's building on.

For example, you could be referencing a third party library that has been installed to your program files directory. This builds fine on every developers machine because they have that third party library installed, but on the build server you would detect the bad reference because the build would fail.

Also, having a CI server run builds and tests on commit will not only highlight the integration issue faster, but can also notify all developers within the team shortly after commit so the source of the problem is immediately apparent.

Upvotes: 5

philippe lhardy
philippe lhardy

Reputation: 3286

First i doubt all projects can afford TDD since it is expensive and often developpers prefers to code directly the feature and forget about tests, even for simpler unit tests. When really applied TDD will detect problems on features, but not necessarily on a full scale of a large project that contains many different components integrated together. A simple example is to group many pieces together each piece working, but failing to use pieces aligned with same api ( oups i used a wrong version of library ...). Having a full product build helps to find problems related to integration. Having it in a continuous fashion helps to find the problem at the time it is introduced, those problem might not be detectable by unit tests since unit test focus on each feature or sub-feature separately.

Upvotes: 1

Related Questions