CODEWITHSUNDEEP
gitjenkinscontinuous-integration
pingu
pingu

Reputation: 8827

Continuous integration build health at odds with push frequency

I am struggling to reconcile the following requirements.

  1. Producing a build for every commit/push (the default behaviour for CI systems as I understand)

  2. Working on large scale projects, that take time to complete, and until completed cause tests to fail.

  3. Pushing often to backup my work

  4. The desire to keep my build healthy by minimising failed builds.

Is there any way to have my cake and eat it?

Upvotes: 0

Views: 29

Answers (2)

Mark Adelsberger
Mark Adelsberger

Reputation: 45819

I'm not sure what you mean by

  1. Working on large projects that can prevent tests from passing for extended periods of time during development

Perhaps you mean that the tests run for a long time, as C-Otto read it. In that case, his advice is more or less correct; unit tests should be quick-running, and if yours aren't it suggests a problem with your test design. It is reasonable to have longer-running tests (sometimes people lump these into "integration tests"), but not as unit tests and, more to the point, you wouldn't run those on every build.

But when I read this point, what I thought you meant is, you have extended periods of development during which some of your tests fail.

Well, either way, this requirement number 2 is the problem according to most modern thoughts about development methodology / best practices. You should not have extended periods when tests don't pass. (And in fact you shouldn't push code that doesn't pass; some people even say "shouldn't commit" such code.)

There are a number of reasons for this, of which the predicament you spell out in your question is one. Of course, you might insist that you like a development methodology in which you simply can't keep your tests in a passing state, and I certainly can't force you to change it; nor will I deny that it's a major undertaking. But if you don't move to practices that let you keep your build clean, then you won't be able to reap the benefits of CI (and in particular continuous testing).

I'd suggest reading up on a development practice like red-green-refactor. This is a highly iterative, test-driven approach. (Please do not be scared off by the term "test-driven"; test-driven is certainly hated by people who learned incorrect models for attempting it, but when done correctly is it extremely effective.)

Upvotes: 1

C-Otto
C-Otto

Reputation: 5853

The main issue seem to be long-running tests. One approach is to only run certain tests with every build (unit tests, component tests) and delay longer running tests to a nightly build (performance tests, system tests).

Upvotes: 1

Related Questions