Eric M Russell (7/21/2015)
jckfla (7/21/2015)
Steve Jones - SSC Editor (7/20/2015)
jckfla (7/20/2015)
Maybe I'm not seeing something right about CI...but to me, it seems to me very loosely defined.I would think Continuous Integration would be related to what (at least during my time/experience/education) would be called a "formal build". That is, it's something that gets tested beyond the standard, informal testing within the group who writes it.
Even though I work in a small group, we still do a code/functional review. That way, my changes aren't truly integrated until it's ensured that it meets more than just my idea of what the specification is I am to meet.
But, maybe I'm not seeing things right. I am a bit old school. I might just need to be put out to pasture....and become a manager. 😎
Yes and no. Depending on the size of your group. Certainly it's automated tests that are run, and whether they are the set of tests a group is supposed to run or a sub/super set, CI ensures the tests are run. Developers, even in groups, do forget to run tests, especially on every build.
However, this isn't some magic new thing that shouldn't be already happening. The difference here is that it's automated and run at the single check in level, at every check in.
Yeah, I guess I am old school. The amount of automated testing I'd do where I am now would be limited. I think the extent of necessary automated testing for my project now is provided by the compiler in Visual Studio. The rest I can handle without having to manage another tool or set of scripts and worrying about if they're configured properly too.
However, that sort of thing would have been great to have 20 years ago when I was working on 300,000+ lines of code in a 20 person project team at a major corporation. That would have ensured nothing would be missed where the likelihood was far more likely. Would have probably kept us from working intensive amounts of hours that we did to ensure everything was working correctly.
300,000 lines of source code?!
That's what I love about programming in a declarative language like SQL; we can say a hell of a lot in only 100 statements.
Yeah...C code. Huge legacy project. We were working on converting it to C++ and trying to make it object driven. But it was such a huge code base, I was on it for 6 months before I was transferred to another project because of my expertise in what they needed there.
Besides, we often didn't work with a DBMS on some hardware. We'd store data locally and manage it ourselves.
I really did learn to love triggers and stored procedures about 10 years ago. It helped a lot, especially in cases of logging change activity and what not. Made it easy to find where things happened and remedy either with a change or with user training.
In one case, it was letting our boss know his little Access table alterations were not local, and he was hosing data in a linked Oracle table. He setup the Access interface himself...because he knew what he was doing. :laugh: