Pro coding
-
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;Gary R. Wheeler wrote:
Our shortest build time is around 50 minutes,
:wtf:
Gary R. Wheeler wrote:
running on an 8 CPU beast with 32G of RAM
:wtf: :wtf:
Gary R. Wheeler wrote:
nd that doesn't include the time required to build the .iso file backup of the build folder.
:wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf:
Getting information off the Internet is like taking a drink from a fire hydrant. - Mitchell Kapor
-
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) :wtf: (It's almost okay because he's had a hard time on other things today. Still a bit irksome though.)
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
-
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
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. :doh:
-
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;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. X|
-
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
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.
-
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; -
I had a nice CI setup once that didn't allow check-ins that don't compile. You should look into that.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost "All users always want Excel" --Ennis Lynch
-
Gary R. Wheeler wrote:
Our shortest build time is around 50 minutes,
:wtf:
Gary R. Wheeler wrote:
running on an 8 CPU beast with 32G of RAM
:wtf: :wtf:
Gary R. Wheeler wrote:
nd that doesn't include the time required to build the .iso file backup of the build folder.
:wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf:
Getting information off the Internet is like taking a drink from a fire hydrant. - Mitchell Kapor
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 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; -
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;