|
I am a mathematician that uses Fortran to build predictive models. 80% of my work is programming. For front ends I use Win forms built in C#. Myself and another are the sole programmers of the system used here. My builds take a few minutes and I can repeat any of them. The users are analysts within the company. If one has a problem, they call me and I walk down to their desk. The entirety of the project is so close to me and familiar that I don't need such formal techniques. My boss has no idea how I do what I do and my actions require little justification.
I have the luxury of living in the old world of programming before trendy techniques with special names. It's quite pleasant. That stuff just would just slow me down.
So, I think my situation is relevant. I don't know of the technique you espouse, nor do I need to. I have been highly successful so far and don't see that changing.
Thanks for looking out for all of us though.
|
|
|
|
|
|
N_tro_P wrote: spending days on a build I've never used CI nor have I ever seen a build even take a day to do or anywhere close to that. You're experience seems quite strange to me.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
|
I think a clear example upfront would have gone a long way against all the confusion.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
|
Don't forget some extras:
- indirect check of source code integrity ("works on my machine" - but forgot to check-in some files...)
- automatic execution of unit tests
- test coverage reports
- automatic code analysis
- reporting over time
- automatic emails for failures
You may also add automated integration / system tests.
And perhaps many more things depending on your choice.
CI helps to keep our code base clean and reliable.
I hope more people will now be able to see the advantages of CI.
|
|
|
|
|
|
That few agree should be a clue. There are many programming realities.
|
|
|
|
|
|
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
|
|
|
|