Tag Info

Hot answers tagged

341

Our strategy is: Check in a failing test, but annotate it with @Ignore("fails because of Bug #1234"). That way, the test is there, but the build does not break. Of course you note the ignored test in the bug db, so the @Ignore is removed once the test is fixed. This also serves as an easy check for the bug fix. The point of breaking the build on failing ...


269

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


159

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


91

Why would you want to allow a build to succeed with known defects? Because sometimes, you have time constraints. Or the bug is so minor that it isn't really worth delaying the shipment of the product for a few days needed to unit test and fix it. Also, what's the point in breaking the build intentionally every time you find a bug? If you found it, fix ...


71

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 ;)


52

Use tags to mark commits with version numbers: git tag -a v2.5 -m 'Version 2.5' Push tags upstream—this is not done by default: git push --tags Then use the describe command: git describe --tags --long This gives you a string of the format: v2.5-0-deadbeef ^ ^ ^ | | | | | SHA of HEAD | | | number of commits since last tag | last tag ...


50

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


49

Tests are there to ensure that you don't (re-)introduce problems. The list of failing tests isn't a substitute for a bug tracking system. There is some validity in the POV that failing tests aren't only indication of bugs, they are also an indication of development process failure (from carelessness to badly identified dependency).


48

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


40

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


29

I've never seen it written out in that form. Where I work, we are using the form MAJOR.MINOR.REVISION.BUILDNUMBER, where MAJOR is a major release (usually many new features or changes to the UI or underlying OS), MINOR is a minor release (perhaps some new features) on a previous major release, REVISION is usually a fix for a previous minor release (no new ...


28

Hudson or Jenkins (the latter is a fork of the former). Reason: It is simple (simple to install and to use) and has great flexibility. The plugins add nearly every functionality I can think of. Some years ago I used damagecontrol. It was also simple to use, but hadn't the plugins. But the author decided that he would give up on the simple solution and ...


26

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


22

"Break the build" means to prevent a build from completing successfully. A failing test doesn't do that. It is an indication that the build has known defects, which is exactly correct. Most build servers track the status of tests over time, and will assign a different classification to a test that's been failing since it was added vs a regression (test ...


22

Actually some people (of noticeable boost fame) are working hard to create and establish such a system called Ryppl. It is hard to establish such a System for C++, because it has no single player which can dictate it. On your second question, a normal package manager (besides not being cross platform) does not handle the specific needs of developers.


20

I think that it adds value even in a single person starting project. The earlier you set it up, the easier it is, and the less time you will have to spend during more crunch times worrying or wishing you had it. Even from the start it will make sure that all unit tests (even if there is one) will get run as often as code is checked in. Otherwise you rely ...


20

An automated build is a description of a process that should cover the following basics: Fetch the latest code from Source Control Compile the latest code into the executable Run tests (unit tests, system tests, integration tests) against compiled code Deploy completed executable to a known location for deployment. Publish the results of the build. 5.1 ...


19

Just use Python. I develop in C++ and do my build scripts in Python, and I would find it painful to do build scripts in C++: Python makes it trivial to manipulate dictionaries, lists, nested dictionaries of dictionaries of lists, etc. (For example, one of my scripts uses a multi-level hierarchy of all of my tools, tools' versions, and tools' versions' ...


18

I think what's important to note here is that regular builds help catch errors sooner rather than later. It doesn't have to be daily, but often enough. Ideally, it can also run your unit tests. The goal is to find out when a build breaks before the final testing phase, to find them as soon as possible. Just set it up to build your main development ...


18

I agree with others here that Maven seems to have taken over most significant projects that I've looked at. While Ant is highly flexible, the build file is not standardized, so when you move to a new project or company, the targets are named differently, the file is structured differently, the inter-target dependencies may or may not be established, etc. ...


15

I use TeamCity at work and at home. It has great support for a variety of build runners and is extensible via plugins. Not dealing with piles of XML for configuration is a huge plus in my books and the free version is sufficient for my home needs. One problem I ran into with TeamCity has to do with trying to get it to automatically version .NET assemblies. ...


15

This senior developer's argument makes no sense to me. They want to add overhead of constantly retrieving & compiling an internal library just so devs can occasionally read the source code? That's going to waste a lot more time than having devs go look at the source code only when they need to check if a feature is available. This is a particularly ...


15

Java is an imperative language, Ant, Maven, etc. are declarative languages: We could define the difference as follows: Imperative programming: telling the "machine" how to do something, and as a result what you want to happen will happen. Declarative programming: telling the "machine" what you would like to happen, and let the computer ...


14

Don't apologize. It's your coworkers who are to blame for not reviewing your first commit and not having a quick feedback system for builds like a continuous integration server. At my current job we have an informal rule that someone who sneakily commits just before leaving work and turns out to break the build has to bring candies/cakes/drinks for the ...


14

I would argue that the failing test should be added, but not explicitly as "a failing test." As @BenVoigt points out in his answer, a failing test doesn't necessarily "break the build." I guess the terminology can vary from team to team, but the code still compiles and the product can still ship with a failing test. What you should ask yourself in this ...


14

One FPGA developer made a small change and started a build. Another FPGA developer made a commit (after he had been told that his changes did not need to be included in this release and that he should wait to commit). After this commit, the initial build failed. The first FPGA developer then had to revert the other's changes, commit his changes, and spend ...


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


13

Don't adjust things to make it compile. Adjust things to be correct. If it was "designed" so that the parameter types didn't match, then the designer doesn't have any idea what they're doing. If you don't want to rely on the compiler, then improve your knowledge of the language. Study the structure of definitions and declarations, and check what you ...


13

IMHO, it is always worth the trouble. Even if you don't have a single unit test and the integration is nothing more than checking out the project and building it you are still coming out ahead. If your CI build succeeds it means any idiot can check out your code and build it. This probably puts you ahead of 85% of software projects on planet earth. I would ...



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