24

I work in a middle sized team which shares the same source code and while have a continues integration in place, but as all of us has to work in the same branch, the build is almost always broken.

As we also have a rule, which has been introduced recently to alleviate the broken builds, which states that no one is allowed to check-in while to build is red.

Having said that, during a day everyone have a handful of 10-15 minutes windows where we allowed to check-in.

And as the team is growing, the windows of check-in opportunities shrinking even more. That forces developers to accumulate their changes locally, which results in a bigger change sets which even more difficult to ensure that the changes are not breaking anything. You can see the vicious cycle.

What can you recommend to allow me to stay effective working in environment like this. Also, please keep in mind that I am a developer, not a manager, and can't change the process or other people behavior much.

  • 9
    Why cant you have branches? – Zavior Apr 06 '13 at 07:41
  • 6
    apparent solution would be to set up your "personal" branch and commit into it, then integrate that branch with one that team works in – gnat Apr 06 '13 at 07:41
  • @Zavior having a branch implies an extra complexity and thus extra work - merging from a branch into trunk. And it also increases to complexity - not only I would need to keep the trunk uptodate, I would have to do the same for the my branch as well. –  Apr 06 '13 at 08:32
  • @gnat Lets say I have my local branch created locally ... I think it would only increase the size of my changesets. And it does not solve the issue with having a 10 minutes check-in window. –  Apr 06 '13 at 08:34
  • 6
    @Andrew accumulating changes at local machine is the first thing to get rid of, no matter what. Other issues you mention are real, too, but this one is first to solve – gnat Apr 06 '13 at 08:54
  • Are people not doing a get latest before checking in? – ozz Apr 06 '13 at 09:01
  • 6
    I don't really understand how they can be pushing changes if they haven't updated locally, and why they're pushing broken builds at all tbh – Useless Apr 06 '13 at 09:22
  • @Useless Depends on the VCS. Subversion allows committing changes as long as there's no conflict with the specific files you're committing. – Izkata Apr 06 '13 at 17:25

7 Answers7

53

To start with, this comment:

... having a branch implies an extra complexity and thus extra work ...

is wholly false. I often hear it from people who aren't accustomed to branching, but it's still wrong.

If you have many developers accumulating changes locally, their local changes constitute a de-facto branch of the main repository.

When they finally push, this is a de-facto merge.

The fact that your branches and merges are implicit doesn't remove the extra complexity you're concerned about, it just hides it. The truth is that making this process explicit might help you (plural = the whole team) learn to manage it.

Now, you say

no one is allowed to check-in while to build is red

but in this case the build can never be fixed, so it can't be quite accurate.

In general, if it's reasonable to build locally (ie, the build isn't too big or slow), developers should do that before pushing anyway.

I assume this isn't the case, because then they wouldn't push broken builds in the first place, but it'd be great if you could clarify this point.

In general the answer to

how to stay efficient when a build is almost always broken

is: stop breaking the build.

Useless
  • 12,380
  • 2
  • 34
  • 46
  • 23
    +9000 for "Stop breaking the build." Seriously. The whole, entire point of continuous integration is to stop breaking the build and, if broken, fix it as fast and as close to the break as possible. – Patrick Hughes Apr 06 '13 at 16:02
  • @Useless, I like you general answer, but I think I should have corrected my question. I personally don't break the build, and at the same time I don't want to make waves pushing others much so they could stop breaking build. I like to know - is there anything I could do MYSELF, to stay more productive MYSELF, in a environment where the build is often broken, and I don't expect that broken state of the to be changed anytime soon. Would like your input on this. Cheers. –  Apr 07 '13 at 04:12
  • 6
    Well, you can work on your own branch, and be selective about which upstream changes you merge onto that branch (ie, maybe merge only when the build is green). But, this is really reducing interaction with the rest of the team, when it would be better overall to fix the team so you can interact sanely. – Useless Apr 07 '13 at 10:29
14

developers... accumulate their changes locally... You can see the vicious cycle.

It's vicious indeed. Accumulating changes locally is a big red flag indicating that something is severely rotten in dev process. It sort of trashes the whole purpose of having a version control system.

As long as you want to stay away from changing the process or other people behavior, the most natural solution would be to set up your own branch and use it to "accumulate" your changes (to be further integrated with team branch when you get a chance).

Actually, if there are more guys like you, you can even collaborate and establish shared development branch to freely exchange your updates without being interfered with incompetent management ideas. Branching allows for many different ways to simplify teamwork.

  • Side note, every time that manager does or says something that forces you to avoid commits, to keep the code locally, translate their words into bold and plain "I am incompetent".

please keep in mind that I am a developer, not a manager, and can't change the process or other people behavior much...

For the sake of precision, you actually can, these are matters of influence and communication skills and one doesn't really need to be in position of power to change things to their liking (search the web for something like "manage up" if you're interested in more details).

However that's rather cumbersome and effort consuming and I can perfectly understand if one simply prefers to stay focused on coding, with little involvement in politics - so if you don't want (even though in theory you can), that's understandable. :)

Community
  • 1
gnat
  • 21,442
  • 29
  • 112
  • 288
7

I'm sensitive to the notion that you feel powerless to change the environment, but I think this situation is a serious challenge to your professionalism as a programmer.

What would happen if a surgeon stored dirty scalpels with the clean ones? What would happen if a plumber didn't test the pipes he installed? What would happen if a violinist always played out of tune with the orchestra?

Why should programmers be exempt from teamwork and common courtesy? As a member of that team, you share responsibility for the result. It's irresponsible to ignore the team as it sabotages it's own efforts.

I'm curious where the rule that "no one is allowed to check-in while to build is red" comes from? It's a good rule if that then focuses everyone on fixing the build. I would try to lead by example and help fix the build whenever it's broken. Let's face it, you're not getting anything else done anyway. If this annoys you, then I would suggest voicing those concerns. The voice of someone actively trying to improve a situation has more influence than the guy who grumbles in the corner.

Steve Jackson
  • 3,595
  • 1
  • 20
  • 27
5

I think that as long as you think that you are "just a developer" and therefore you cannot change things you are going to suffer from this problem.

What you need to do is that you need to revert every commit from the repository every time when someone breaks the build and then tell that guy that he just broke the build and that needs to stop. You also need to explain this situation to the manager and tell him that your team's productivity is suffering because of this problem.

You need to do whatever you can to change the process better and rather say you're sorry later instead of asking for permission.

I think that you and your team are in a situation where the process needs to be changed and you cannot work efficiently with that broken model. I also think that it's your responsibility to do something about that problem when you have recognized it. If no-one else's going to do anything about the problem, you are the one who must!

hequ
  • 171
  • 2
2

I can relate to your plight, I faced a similar situation with my most recent project at work. We ended up implementing sort of a "hot potato" system where the developer that most recently broke the build had to babysit/nanny/monitor it until it was fixed AND passed all of our verification tests.

This was successful because the build and verification tests routinely took ~4 hours, so breaking the build meant you lose half a day in doing real work. Needless to say this resulted in developers using branches more efficiently before merging them into the trunk. For most developers, the previous mindset was "I'll just let the CI build system notify me if my code is broken."

Sam Miller
  • 121
  • 3
1

A simple change to the CI system would do it: any change that breaks the build gets rolled back automatically. Even better, let the CI repository become a staging area, where changes only get pushed through to the authoritative repository when the build is green. Tools like Gerrit can help here.

William Payne
  • 1,161
  • 8
  • 20
  • 3
    But to make this task impossible "...keep in mind that I am a developer, not a manager, and can't change the process..." – SChepurin Apr 07 '13 at 10:39
  • @SChepuriyour your process is inefficient, you meed to change the process, period. As a developer, you may not be able to approve the change, but you can always work towards process improvement. – oefe Apr 07 '13 at 15:09
1

Two other things could help here:

  • can your team smoke test a CI build locally? If you check that you don't break the build -- or at least don't break the build in common ways without having to commit and trigger management and team ire.
  • there are many ways to define broken builds depending on how you architect CI. This includes defining broken -- under heavy development we don't consider failing tests a break but rather another goal to work towards.

But you should really look at branches.

Wyatt Barnett
  • 20,685
  • 50
  • 69