|
Thanks for the responses.
|
|
|
|
|
I don't think it's important that I know so move along.
|
|
|
|
|
Agreed until proven otherwise!
|
|
|
|
|
It's a fancy word for 'applications that replace build scripts'.
|
|
|
|
|
Don't use 'em <= Don't know what they are.
Looking it up, I've so far found the "BUILD ALL" button adequate for the purpose of "BUILDing ALL".
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
It's fine for me as well - that's why "I don't use" fit me well.
But...if I was in a medium-to-large team then I can see where it would be very useful, to ensure that different developers aren't working at cross purposes as early as possible so you haven't wasted huge amounts of time when you do try it.
I work on a simple basis: "if it doesn't compile, don't check it in". With a team, anything which extends that to "if it compiles but breaks the whole team build, go forth and multiply" has got to be a bonus! 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
So - you caught me as a lone-wolf?
Actually, even when working with someone else, we sit together and figure out what we want and then go do it. Possibly luck, but integration has been seamless and robust. No doubt, if it were a team-size effort, it would be challenging.
Actually that comes back into real life. We've a contractor here and he won't share - he wants details from me/us, but doesn't let me/us in on what he's doing. I won't go into the gory details, but clearly, if one works with an a**hole one should expect it to try to sh^t on you.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
W∴ Balboos wrote: he wants details from me/us, but doesn't let me/us in on what he's doing
Now that is a problem, I would be insisting he check in VERY regularly and then review his stuff.
I agree with OG, a medium+ team can benefit from continuous/automatic integration or builds, we currently have a max of 2 devs on a project so treat them like LWs.
I have worked on a project where we had 10 devs and 3 QAs, smoke test build every Thursday, whoever broke the build bought the first round on Friday, sometimes after staying up all night to fix the build!
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
There's no place for him/his group-in-India (surprise! ?) to check in.
They've been with the company a long time (longer than I) and their behavior is institutionalized. I do my stuff and when their stone wall gets in the way I stop. Making sure, however, that the reason I stopped is understood.
Like is common for this type of contractor, they're grasp of abstract solutions is weak: they plod along in text-book fashion and a complete lack of insight. We're not a software company, so a working product, no matter how written, will be acceptable to management.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
If so - to what purpose?
(Not intending to be snarky - just wondering what the ones listed above don't do...)
|
|
|
|
|
I lied a bit, because CruiseControl.NET was not in the list 
But I did develop some 'tooling' around it.
|
|
|
|
|
Once upon a time ...
There was no tools available, or at least not that suited us (and we're talking mid/late 90) ... and I'm a great believer in "If it works, don't mess with it!".
rgds /Jonas
|
|
|
|
|
Recently I inherited an old JIT compiled ASP.Net 'Web Site Project' - which does not play nicely with anything, and takes about half an hour to start up if you run a Web Deploy. In the end I spent a couple of hours hacking some deployment scripts in NodeJS so I could only have it compile the necessary files.
Every purpose built CI system seems to assume that you're able to do the sane thing and compiling your application before deploying it.
|
|
|
|
|
We have.
We have a simple C++ app on SubVersion.
Our tool get the latest commit, build, launch tests, copy EXE results (and sends emails on success/errors...)
the only thing missing is the installer, but that is no biggie it is "task scheduled" on another machine.
I'd rather be phishing!
|
|
|
|
|
Yes. We use Jenkins to migrate all of our code, but it doesn't do a good job with the database. So I wrote a DatabaseCI tool that we use in house. All SQL changes must be scripted and run through this tool. They are checked into branches, so when a branch gets merged, so do the DB changes. Then the builds are seamless as you know all DB changes are good.
One of the best benefits of the tool is that it gets rid of any resource (procedure/function/view) that isn't in the script. So you don't have one guy with production access making emergency fixes that nobody knows about. If it isn't scripted, it wont' exist after the next build. It keeps everybody honest!
Hogan
|
|
|
|
|
|
If I could share my project, I would. It took about 2 weeks to write and minor tweaks, but all the major bugs were worked out in the first 2 months of using it. Once developers got over using it, they understood the benefits and nobody complains anymore. Especially if you are in charge of a release!
I based my work off K Scott Allen's blog posts. Start with these two and then you can probably find others. He outlines what needs to be done very well!
Three Rules for Database Work[^]
Versioning Databases – The Baseline[^]
Hogan
|
|
|
|
|
The right tools, processes and philosophies can waste the company a lot of time.
"Program testing can be used to show the presence of bugs, but never to show their absence."
<< please vote!! >></div>
|
|
|
|
|
Isn't that per definition the wrong tools etc.?
|
|
|
|
|
perhaps... but my what I am referring to over here is that too much time can be spend on tools/processes and at the end of the day it can waste a lot of money. The tools etc. aren't the problem in this instance, but the time spend on it. It is how we use these which are important, less so the what tools ect. we use.
Don't get me wrong... there are a lot of tools out there which is wrong, I'm not denying that fact.
"Program testing can be used to show the presence of bugs, but never to show their absence."
<< please vote!! >></div>
|
|
|
|
|
Cruise control ()[^] is missing from the list.
|
|
|
|
|
Second that, minimal and simple to use, love it!
|
|
|
|
|
Also using CruiseControl.NET, it is not as bloated as TeamCity for instance.
But 'simple to use' is a term I would not use 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
