July 21, 2015 at 7:03 am
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.
July 21, 2015 at 7:15 am
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.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
July 21, 2015 at 7:33 am
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:
April 1, 2016 at 9:10 am
David.Poole (7/16/2015)
...treat the source control trunk as sacrosanct, it should be the code that is in production...
Always.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
April 1, 2016 at 8:48 pm
jckfla (7/20/2015)
Seems to me, a lot of the changes being pushed out so fast in tech now aren't doing anything significant. There are exceptions, but the vast majority are either shining the tech bauble or reorganizing it. Substance, in a lot of commercial software releases I see now, seems to be lacking.
Heh... I'll use the "Ribbon Bar" as an example. It was a huge paradigm shift for many and, for many tasks, now takes many more clicks to get to the exact same menu as on the older menu.
For SQL server, it's deprecation of useful items and inclusion of partially complete items that still aren't complete. The PIVOT function is a great example of a partially complete item. Take a look at the PIVOT function in ACCESS and see what it could be in SQL Server.
And then there are things like the newly incomplete SPLIT_STRING() function and the absolutely horrible performance associated with the FORMAT function (44 times slower than CONVERT, and that's the BEST case).
There's a lot of hype on "new shiny objects" but things like the still missing "Tally Table" function (still an open item on CONNECT after 10 years), coming up with serious needs like more effective ACE drivers and a BULK EXPORT, or even coming up with a service pack that won't wipe out SSIS or cause ONLINE rebuilds of Clustered Indexes to corrupt the table just don't seem to be in the cards anymore.
People seem to have forgotten any semblance of usability, reliability, or even basic quality and not just in software. "Let the users test it in the field" seems to have become the mantra instead of "lets make the absolute best platform possible". People have also forgotten that "If you want it real bad, you'll probably get it that way".
--Jeff Moden
Change is inevitable... Change for the better is not.
January 19, 2017 at 4:09 pm
Currently assisting a client to achieve this. They are years in but only in the last 12 months have they reaped great rewards from their efforts and can see that it can be completed. This is in part to the mix and age of the technology stack and their road map. Their commitment is being rewarded and I estimate that in 2 years they will be in a happy place. Seems like a long time? The product is over 25 years old.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
January 19, 2017 at 5:41 pm
If you had the opportunity to establish the processes and infrastructure to accomplish CI/CD from the ground up in a new company, how would you start?<
January 19, 2017 at 10:58 pm
Lynn Pettis - Thursday, January 19, 2017 5:41 PMIf you had the opportunity to establish the processes and infrastructure to accomplish CI/CD from the ground up in a new company, how would you start?<
For me, I'd say that this is the order I'd look to make changes.
1. Get a VCS setup. These days I'd just say use Git. Either Git along or Git/TFS, but use Git. Have developers storing all code in repos, get used to managing code, committing, and reverting as needed. Branch minimally, but learn how to do this. I would recommend separating the db and app code, but there are reasons to keep things together. Up to you.
2. Start CI. Learn how to build things. TFS makes this really easy, but TeamCity is nice as well. Bamboo works well, Jenkins is more of a pain, but pick one, learn to build Hello World, learn to build a db. Either use something like the Redgate tools or write custom scripts. Get a build working.
3. Add Unit tests. Do this as you write code. The power of CI in ensuring that things work is with tests. Don't try to get 100% coverage. Get coverage for the things that you are working on that get caught in testing as bugs.
4. Learn to deploy code. Get an artifact from your CI and deploy it to new machines (or VMs). Learn how your code gets copied and executed. What problems do you have. What issues come up.
In all these things, don't try to be 100%. Get something working and use manual or the same process you've been using for the rest. As you can automate things, do it, and where you can't, live with it.
CI/CD/DevOps is mostly changing your culture to try and get better and take steps to solve problems or make something easier as you can. Where you can't , live with it. Where you can, just take your manual process and automate it, even if automation requires a person to do something.
January 20, 2017 at 5:11 am
Additionally to what Steve says, slowly. One step at a time and be continually prepared to adjust your course. Have confidence in yourself and your team and treat everything that you read as advice as opposed to instructions.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
January 20, 2017 at 7:41 am
Gary Varga - Friday, January 20, 2017 5:11 AM... treat everything that you read as advice as opposed to instructions.
This is great advice. I might use this, if you don't mind, Gary.
January 20, 2017 at 7:50 am
Steve Jones - SSC Editor - Friday, January 20, 2017 7:41 AMGary Varga - Friday, January 20, 2017 5:11 AM... treat everything that you read as advice as opposed to instructions.This is great advice. I might use this, if you don't mind, Gary.
Help yourself Steve.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
July 28, 2021 at 7:52 am
This was removed by the editor as SPAM
July 28, 2021 at 3:09 pm
I think CD can be incredibly efficient for application code. For db code, it's more complex. A change in the db is a fundamental one that could cause more problems than it helps. Or you could end up thrashing as you work through a design, changing too much too often. I think that table changes need more consideration. OTOH, I think running stored proc changes through CD could really help improve performance and the experience for customers.
July 28, 2021 at 6:25 pm
I agree, database code is more complex and therefor requires more thought when bringing the database into a CI/CD pipeline. At the same time I believe it is important to do so as well. For too long the database has been the red haired step-child, ignored by the DevOps world but it is a vital part of application systems. This means it needs to be kept in step with new and changing features of applications.
Viewing 14 posts - 31 through 43 (of 43 total)
You must be logged in to reply to this topic. Login to reply