April 13, 2015 at 11:57 pm
Heh... continuous integration is the only way that you can make the maximum number of mistakes before anyone can even blink because, although humans can really make a mess of things, it takes a computer to really screw things up quickly. 😛
We don't even attempt it anymore.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 14, 2015 at 1:07 am
We have a TeamCity (TC) server which we use to automate many repetitive jobs, in the spirit of CI.
Such things include:
1) Moving changes from source control to QA databases
2) Building and deploying SSIS ispac files
3) Creating drift reports for production databases
4) Running Powershell scripts to check (and set) server config settings
5) Sending alerts if certain production database criteria are met
6) Sending alerts in the event of build failures for QA or production databases (we use VS database projects)
7) Building and deploying web sites.
The next thing we intend to automate is the restore of prod databases to QA. I know that this can be done outside of TC, but not with the same level of ease and visibility to non-SQL Server users.
The absence of evidence is not evidence of absence
- Martin Rees
The absence of consumable DDL, sample data and desired results is, however, evidence of the absence of my response
- Phil Parkin
June 2, 2015 at 9:45 am
Steve,
I am not sure what VCS stands for in the phrase "There are people that follow a change script process, producing and saving .Sql files for all changes in VCS" or in "If you're using a VCS, and you should be, you'll have copies of old code to easily undo a change if it's a mistake" -- are we talking Version Control System? Please expound. Thanks.
Marty
June 2, 2015 at 9:53 am
mcmangold (6/2/2015)
Steve,I am not sure what VCS stands for in the phrase "There are people that follow a change script process, producing and saving .Sql files for all changes in VCS" or in "If you're using a VCS, and you should be, you'll have copies of old code to easily undo a change if it's a mistake" -- are we talking Version Control System? Please expound. Thanks.
Marty
You've got it right, Marty - Version Control System. (Git, TFS, etc. even Source Safe might qualify 🙂 )
June 2, 2015 at 9:58 am
Thanks, Peter! I've been around TFS before, but found it used for front-end application code only, not involved with database updates. I'd be happy to see a separate topic thread on this sometime, including the Build-Your-Own (RYO) variety.
Thanks again.
Marty
June 3, 2015 at 3:56 pm
Well, we used SSDT SQL Projects for our databases. We used Git for version control, but could have used anything - it's just files behind the scenes. To push the changes, we used Jenkins, but again any platform can work there with a little work.
I've also seen people roll their own sets of scripts, making each change idempotent so it can be rerun at any point. Those changes are then rolled up through some other interface that knows how to interpret the files. There are even some packages that handle that as the norm - DBDiff does that, IIRC. I'm a bigger fan of the Red-Gate or MS method overall. They basically say "I want the DB to look like this - make it happen". Both have support for smart renames so you shouldn't have to worry about someone renaming an object and the compare thinking that this means "drop old, create new".
June 8, 2015 at 10:01 am
Thanks, Peter.
Apologies, Marty. I do try to spell out the acronyms most times, but didn't hear. VCS is Version Control System, also known as Source Control. I'll try to do some more writing and produce some content on using your database with a VCS.
Viewing 7 posts - 16 through 21 (of 21 total)
You must be logged in to reply to this topic. Login to reply