August 8, 2015 at 11:09 am
Comments posted to this topic are about the item Deploy from VCS
August 10, 2015 at 5:42 am
Code, I'd be 100% confident on all except the gnarliest legacy projects.
Database wise I would not like to do such a redeployment.
August 10, 2015 at 7:22 am
I know you're just talking hypothetical to make a point about source control dilligence and what we could do, if we believed it was maintained perfectly. However, it's hubris, not confidence, for any of us to think that we could adequately re-deploy everything from source control in the event of an actual disaster recovery scenario.
I will say that I maintain a TFS folder called \deployment, and I create a TFS sub-folder beneath that for each change order, the name of the sub-folder based on the CO number. Each script attached to the CO is copied and checked into the CO sub-folder. So, I always know exactly what version of scripts were included in each deployment. That's where I go when we need to do a rollback or to confirm what the difference is between the lastest version in development and the last release to production.
I know that's irregular, and it's based on the pessimistic assumption that source control is not properly branched and versioned, and source control can't be counted on to reflect production perfectly. However, as far as I'm concerned it's outcome that matters most, and the various processes we use are just tools and guidelines to help insure outcomes. When I do a rollback, I want to use what I know to be the previous release, not what should be the previous release, especially if I'm rolling back another developers code at 5 PM on a Friday afternoon.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
August 10, 2015 at 8:59 am
It is true that we can't adequately redeploy everything from source control when we are talking about production deploys. We have think about data loss and how we handle that, but what about continuous integration?
We have successfully implemented full repeatable and automated deployment processes (including databases) across all our dev, QA, and staging environments in many developments teams over the years with the lynchpin of these processes being a Distributed Version Control System (like Git). Because of the disparate branching strategy of TFS (and other centralized VCS) we found it to be very difficult to have isolated feature development and high confidence in what is going out in our releases. DCVS's help take the work out of manually managing a deployment directory and still have a complete understanding of what is being deployed in every release. If used correctly, it also removes the prep-work that can occur when a database manually has a stored procedure applied here, a table change applied there, etc. Otherwise, how would we ever know what changes are supposed to be deployed with the multitude of features/fixes that are being developed for each release?
August 10, 2015 at 12:58 pm
I'm not sure it's hubris, but more a question of having a view of your code that you can count on for future work. Certainly some of us work in an evolutionary manner. What I put in VCS today depends on what I put in at some point in the past, and I'd need to deploy the past item + today's to get to the current production value.
Ex: create table + alter table w/ new column. I can't deploy the latest ALTER without the first CREATE.
This is really to highlight the idea that no code is untouchable and it's all stored somewhere. I don't have code in a database or application that was never put into a VCS, and exists without history. Certainly people make hot fixes, and that's an issue if those are not fed back into the development systems (and VCS).
August 10, 2015 at 1:01 pm
Charps (8/10/2015)
It is true that we can't adequately redeploy everything from source control when we are talking about production deploys. We have think about data loss and how we handle that, but what about continuous integration?We have successfully implemented full repeatable and automated deployment processes (including databases) across all our dev, QA, and staging environments in many developments teams over the years with the lynchpin of these processes being a Distributed Version Control System (like Git). Because of the disparate branching strategy of TFS (and other centralized VCS) we found it to be very difficult to have isolated feature development and high confidence in what is going out in our releases. DCVS's help take the work out of manually managing a deployment directory and still have a complete understanding of what is being deployed in every release. If used correctly, it also removes the prep-work that can occur when a database manually has a stored procedure applied here, a table change applied there, etc. Otherwise, how would we ever know what changes are supposed to be deployed with the multitude of features/fixes that are being developed for each release?
A deploy from VCS certainly wouldn't have your production data. But if I could bcp out/in all the data from production, would it look the same?
I'm a bit confused as to how you have separate branches in a DVCS that allows you to have confidence in what's going out in releases? If you have fixes that are deployed from one code in the DVCS, but not necessarily in other nodes, then isn't that an issue? If you are regularly resyncing from other nodes (push and pull), then aren't you ensuring you have a centralized set of fixes?
Or are you counting on merges and conflict resolution in your DVCS to notify you issues before you deploy?
August 10, 2015 at 1:41 pm
I guess one could bcp data after a schema deploy and it would all look the same, but that's also very time consuming. If we had source data (not stored in source control) as an option to get data into a deployed schema, then that's reasonable. What we typically do is restore a cleansed version of production and upgrade it from VCS (usually in Staging); thereby ensuring not only a full deploy works well from VCS (which we perform in Dev & QA) but also that the upgrade path works as well.
With separate branches in a DVCS, we always merge our deployed code back into our release & integration lines; solving merge conflicts as best we can. (We are all human, after all). Then we let our CI process deploy those changes back out to QA to ensure that our merges don't break the features we've already released but also that merges don't break the finished features slated for a future release. Our automated regression tests then catch the errors we made merging. These merge conflict resolutions also occur regularly (almost daily) as we merge back up into our integration lines and subsequent release lines.
August 11, 2015 at 10:20 am
Charps (8/10/2015)
I guess one could bcp data after a schema deploy and it would all look the same, but that's also very time consuming. If we had source data (not stored in source control) as an option to get data into a deployed schema, then that's reasonable. What we typically do is restore a cleansed version of production and upgrade it from VCS (usually in Staging); thereby ensuring not only a full deploy works well from VCS (which we perform in Dev & QA) but also that the upgrade path works as well.With separate branches in a DVCS, we always merge our deployed code back into our release & integration lines; solving merge conflicts as best we can. (We are all human, after all). Then we let our CI process deploy those changes back out to QA to ensure that our merges don't break the features we've already released but also that merges don't break the finished features slated for a future release. Our automated regression tests then catch the errors we made merging. These merge conflict resolutions also occur regularly (almost daily) as we merge back up into our integration lines and subsequent release lines.
The idea of deploying from VCS isn't that you'd actually do it, but that you have confidence in your code and VCS. I would never want to deploy a database from VCS and then move production data unless I was concerned we lost code somewhere. In that case, I'd probably end up pulling production back into the VCS and making it the head. Then going through objects to see what had changed and where we could move forward.
Your DVCS seems more like delaying merges until someone is ready, and in that case I'm not sure it's different than branching in CVCS, but if it works, good for you.
August 18, 2015 at 7:30 am
Yes, I'm confident. Yet it would still be a bit scary.
March 7, 2016 at 5:05 am
Iwas Bornready (8/18/2015)
Yes, I'm confident. Yet it would still be a bit scary.
Confidence suggests that you have planned and tested...being scared suggests that you have remained sane.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply