|
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
