|
16.40: Make last minute change to code base
16.42: Check in
16.44: Go home
16.46: CI server gets around to completing the build from your check in
17.16: I look at the CI server and discover that you broke it
17.35: I finish cleaning up the tests you should have done (and aren't around to fix tomorrow)
(It's almost okay because he's had a hard time on other things today. Still a bit irksome though.)
|
|
|
|
|
You don't have the plug in that cuts off the water supply at the developer's house when they break the build?
|
|
|
|
|
There's always bottled water to make some coffee. Just keep your paws of my internetz, and we can get along nicely.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Duncan Edwards Jones wrote: You don't have the plug in that cuts off the water gin supply at the developer's house when they break the build?
|
|
|
|
|
You might be onto something, a certain someone has been pretty quiet today. 
|
|
|
|
|
I had a nice CI setup once that didn't allow check-ins that don't compile. You should look into that.
|
|
|
|
|
See below. Also, this build did compile, but it failed its unit tests.
|
|
|
|
|
A build that takes 4 minutes? Our shortest build time is around 50 minutes, running on an 8 CPU beast with 32G of RAM, and that doesn't include the time required to build the .iso file backup of the build folder.
Software Zen: delete this;
|
|
|
|
|
|
Our build time roughly breaks down into:
10% - pulling source out of source control
50% - compiling application
20% - compiling installer(s)
20% - creating distribution media structure, copying data
Software Zen: delete this;
|
|
|
|
|
|
We don't do automated unit testing (GASP! OH THE HUMANITIES!). Frankly, given the scope of this code, if we were to run tests during the build, builds would take days.
Software Zen: delete this;
|
|
|
|
|
Sounds like the job I had a few years ago; 2 million line codebase, image processing 'unit' 500,000 LOC (C++), and I had to build and test the entire unit in each attempt at an iteration.
The sole advantage was that the mod was to produce an offline test, so it was supposed to be run offline. Otherwise it would have been mounted on a one tonne machine in the lab. (Which was how I generated the offline data).
In the end I had 20,000 lines of additional code distributed in thousands of locations(no decoupling here), and it all worked.
Merging a build into a release took a week and had to go through the build captain. If you fluffed source control your mods didn't make it in for months. 
|
|
|
|
|
This current project is pretty small, I've worked on ones where running the system tests took ~90 minutes and screwing something up in that one was more of a pain.
|
|
|
|
|
This happened a lot at my previous company. After installing a TFS Build Server and configuring all checkins as gated we never had that problem again. If you break the build your code just comes back to you. Everybody hated this in the beginning, but once they realized that everything worked when getting latest they warmed up to the idea. This was a great way to resolve the "it builds on my machine" problem.
My plan is to live forever ... so far so good
modified 12-Dec-13 2:51am.
|
|
|
|
|
We don't put 'code' in control right away.
After build, there is dogfooding. Then there is a test plan.
You can back it up in any number of secure places, but until it passes tests it doesn't go to Valhalla. 
|
|
|
|
|
We considered gated builds and reckoned that given the pace of development it would cause us more pain in merge conflicts than it would gain us in keeping the build green. We're a small team that's pretty good at build discipline so we don't have any serious issues in this vein.
|
|
|
|
|
Same here. It's unusual for someone to break the build, and not traumatic when they do.
Software Zen: delete this;
|
|
|
|
|
|
Quote: NoFlo
Pepto Bismol[^] is good for that.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
Ok, that kinda sucks...
I've been working on something similar called VisualScript for some time now. Its integrated into one of my products but I've been working on version 2 which will be stand-alone.
VisualScript Editor (Test Environment)[^]
Seems to be almost exactly what NoFlo is, except in Version 1 you could not edit the code inside the blocks, Version 2 will have that ability.  Guess I should have done a KickStarter.
|
|
|
|
|
Nice!  
There's also VS Code Maps[^] and Visustin[^] out there.
P.S. - The competition might be good for you if you can outdo them in some way. Another scenario is that they might buy you out.
|
|
|
|
|
Nice looking design !
"What Turing gave us for the first time (and without Turing you just couldn't do any of this) is he gave us a way of thinking about and taking seriously and thinking in a disciplined way about phenomena that have, as I like to say, trillions of moving parts.
Until the late 20th century, nobody knew how to take seriously a machine with a trillion moving parts. It's just mind-boggling." Daniel C. Dennett
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
