Stack Exchange Network

Stack Exchange network consists of 175 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Visit Stack Exchange
305

Don't apologize! Breaking the build once in a blue moon is not a big deal, and should never be a show-stopper. It's your manager's fault for not configuring continuous, automated builds. Also, I bet your team fails the 'Joel Test' and can't make a build in one step. If so, this would be another thing that you shouldn't apologize for. Indeed, it's a ...


220

Surely, by the time something gets committed to master, a developer has already run all the unit tests before and fixed any errors that might've occurred with their new code. Or not. There can be many reasons why this can happen: The developer doesn't have the discipline to do that They have forgotten They didn't commit everything and pushed an incomplete ...


182

Bagels. Donuts. Etc. At one company I worked for in the past, checking in broken code or otherwise causing colleague disruption is generally resolved by the bringing in of apology foodstuffs the next day. We had a guy blow away a production database one day, causing massive panic and a late night for the whole team. The next day he grilled burgers for ...


103

With 65 billion tests, it sounds like you're being asked to test all possible inputs. This is not useful--you'd essentially be testing that your processor functions correctly, not that your code is correct. You should be testing equivalence classes instead. This will drastically reduce your range of test inputs. Also consider whether you can subdivide your ...


87

It depends to some extent on how your team usually works, but I would say that was fine. Keeping the build working saves everyone else time. It's polite for the the second programmer to drop the first an email to explain what he has done, just in case a specific version of the library is needed or there is some other complication. It's also a slightly ...


80

the question is should we use branches nowadays? Well about half year ago I was assigned to perform a study to answer that question. Here's the summary, based on references studied (listed below) there's no commonly agreed "best" branching strategy applicable to any project most resources seem to agree that choosing productive strategy depends on the ...


79

Two quotes for you: The man who makes no mistakes does not usually make anything.--William Connor Magee Anyone who doesn't make mistakes isn't trying hard enough.--Wess Roberts I agree with Jim G., don't apologise but do learn from it and don't make the same mistake again... keep it DRY ;)


74

As a developer who doesn't run all the integration and unit tests before making a commit to source control, I'll offer up my defense here. I would have to build, test and verify that an application runs correctly on: Microsoft Windows XP and Vista with Visual Studio 2008 compiler. Microsoft Windows 7 with Visual Studio 2010 compiler. Oh, and the MSI ...


64

Unless you are all working out of the same working tree, you are using branches, whether you call them that or not. Every time a developer checks out into his working tree, he creates a separate local branch of development, and every time he checks in he does a merge. For most teams, the question isn't if you use branches, the questions are how many and ...


54

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 ...


54

I would be against doing this for the following reasons: Any time you set up an automated tool to change code on your behalf, there is the risk that it will get it wrong, or that a situation will arise where you need it to stop making that change (e.g., the latest version of Google Mock had a bug in it, so it's not your code failing) and you have to waste ...


53

Don't apologize, just FIX IT as soon as possible. It is okay though, everybody breaks the build at least once, in my last company it was something of an initiation ritual. When a team member broke the build we would put a rubber duckie on his desk in the morning before he came in, this let him know he broke the build and he would fix it. We called it the ...


53

This question is really two questions in one. Todo comments Of all the ways to track action items, this is the worst. TODO comments are good during active work or as a way of suggestion to a maintainer, "here is something that could maybe be improved on in the future". But if you rely on TODO comments for getting work done, you're doomed to fail. What ...


43

"Sorry! My bad!" is how I usually apologize when I've broken the build. It happens. But as others have said, this is an opportunity to improve your systems so that one person cannot so easily break the build for everyone else. I would not make a formal apology in these circumstances, but if you actually feel that a more formal apology is appropriate, then ...


43

Your build number won't be reset to 0, when minor and major versions increase, this violates sections 7 and 8 of the specs: Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API. It MUST be incremented if any public API functionality is marked as deprecated. It MAY be incremented if ...


42

You should look at git-flow. It's an excellent (and popular) branching model. Git Flow Summary Branching The main trunks that stay around forever are develop and master. master holds your latest release and develop holds your latest "stable" development copy. Contributors create feature branches (prefixed with feature/ by convention) off of develop : $...


40

Let me be the one to disagree with my fellow answerers. This is known as Gated Check-ins in the TFS world, and I expect elsewhere. When you attempt to check-in to a branch with the gated check-in, the shelveset is sent off to the server, which makes sure your changes build and the specified (read: all) unit tests pass. If they don't, it notifies you that ...


39

If this is a real test suite, then you don't want to get anywhere near working on it. The whole job of a tester is to strike a balance between testing thoroughly enough to be confident you've got the "right" results and writing few enough tests that they can be run in a reasonable amount of time. Many tests can be abstracted into "equivalence classes", ...


35

No, it's not, for two reasons: Speed Commits should be fast. A commit which takes 500 ms., for example, is too slow and will encourage developers to commit more sparingly. Given that on any project larger than a Hello World, you'll have dozens or hundreds of tests, it will take too much time to run them during pre-commit. Of course, things get worse for ...


33

It's not how many developers, but how many steps it takes to get from 1 to n (inclusive), where 1 & n are ... 1: Checking out code And n: having installable\deployable packages If n < 2 you maybe don't need CI otherwise, you need CI Update From reading your findings I can only conclude that you approached CI from the wrong direction and for the ...


32

Fail fast is a good principle - the sooner you know the build is broken, the sooner the offending commit can be identified and the build fixed. Build on every commit is the right thing to do. Building every 15 minutes can be pointless if the project has a high volume of commits within such a timeframe - tracking down the bad commit would take longer and ...


32

Continuous integration as a term refers to two distinct ideas. The first is a workflow: instead of everyone in a team working on their own branch and then after a couple of weeks of programming try to merge their changes into the mainline, that changes are integrated (nearly) continuously. This allows problems to surface early, and avoids incompatible ...


30

I guess for your marketing department it is not important how CI works, but what CI means for new releases of your software. CI will ideally mean that you can produce a new potentially releaseable version of your software every day, ready to be presented or sold to your customer, with some new features, functionality or bugfixes added. That does not mean ...


29

First and foremost: each person is responsible for the build process. It sounds like members in your team are not mature... No one gets away with writing code and fobbing it off to the CI server hoping that it works. Before committing code, it should be tested on their local machine. You should be sure that the code you're checking in isn't going to break ...


28

my years of software development experience suggest that in practice it can't work. Have you tried it? Dave and I wrote the book based on many collective years of experience, both of ourselves and of other senior people in ThoughtWorks, actually doing the things we discuss. Nothing in the book is speculative. Everything we discuss has been tried and tested ...


27

Personally, I choose option 3: keep versioning information in VCS metadata, specifically, tags. Git makes it very easy to do so, because there is a command git describe, which can uniquely describe a commit based on a tag. Here's how it works: If the current commit is tagged, output the name of the tag. Otherwise, walk the history backwards until you find ...


26

Disclaimer: I work for Atlassian DVCS does not discourage Continuous Integration as long as the developer pushes remotely on a regular basis to their own branch and the CI server is setup so that it builds the known active branches. Traditionally there are two problems with DVCS and CI: Uncertainty of integration state - unless the developer has been ...


26

Let's agree on terms first. I personally use the terms Continuous Build and Continuous Integration to distinguish two different scenarios: Continuous Build: a tool that checks periodically if the repository changed since the last build, and build/test if it did. Continuous Integration: a tool that takes Pull Requests and validate them against the latest ...


Only top voted, non community-wiki answers of a minimum length are eligible