Database version control and deployment - model or migration scripts
•Download as PPTX, PDF•
2 likes•3,378 views
For the last few years Microsoft and others have been promoting declarative, model-based database development. For many this is the way forward – design the desired state and let software work out the upgrades. Gone are the days of managing endless upgrade scripts and manual deployments. At the same time, leaders and shakers of our industry including Jez Humble, Pramod Sadalge and Paul Stovell promote an iterative, migration script driven approach asserting that deployment scripts should be tested early and not generated by software. They often assert that a disciplines migrations approach is the only reliable way to achieve database continuous delivery. So many presenters have opinions that one of the approaches is the “right” way and the other is the “wrong” way. However, like with most complicated problems, the truth is that it depends. I’ll illustrate the relative strengths and limitations of each approach with a simple scenario. I’ll describe teams and databases that are better suited to a model or a migrations approach, and whether it’s possible to get the best of both worlds. You’ll leave this session with a better understanding of what options are available to you and which is more likely to work for your team. With so many teams struggling to apply continuous delivery to their databases it’s important to consider whether the problems you are facing are because you have taken an approach which is fundamentally unsuitable for your database.
Recommended
Recommended
More Related Content
More from Alex Yates
Recently uploaded
Recently uploaded (20)
Database version control and deployment - model or migration scripts
- 1. @_AlexYates_ #SQLRelay State-Based or Migrations-Based Database Development? A Review of the Pros and Cons… Alex Yates
- 9. @_AlexYates_ #SQLRelay A cursor?! You just CAN’T do that?!
- 10. @_AlexYates_ #SQLRelay #worksOnMyMachine A cursor?! You just CAN’T do that?!
- 11. @_AlexYates_ #SQLRelay Hey, you just dropped my hot-fix!
- 12. @_AlexYates_ #SQLRelay #worksOnMyMachine Hey, you just dropped my hot-fix!
- 13. @_AlexYates_ #SQLRelay Farm Credit Services of America (FCSA) • 100 person IT team, 14 sub-teams • Database version control inconsistent • Deployment process manual • Delivery was slow and unreliable
- 14. @_AlexYates_ #SQLRelay Farm Credit Services of America (FCSA) • Deployments easier to review • Delivery faster and more reliable • Standardised source control and delivery process • Automated manual deployment tasks
- 15. @_AlexYates_ #SQLRelay The automated deployment pipeline
- 16. @_AlexYates_ #SQLRelay Databases are hard • Schema changes vs existing data • Reference data vs production data • Teamwork and testing • Database drift (change outside process, e.g. production hot-fixes)
- 17. @_AlexYates_ #SQLRelay There’s more than one way to skin a cat
- 18. @_AlexYates_ #SQLRelay There’s more than one way to skin automate a cat
- 23. @_AlexYates_ #SQLRelay “There's nothing more reliable than keeping track of exactly the scripts you intend to run, and running them, without trying to compare state and guess.”
- 24. @_AlexYates_ #SQLRelay “There's nothing more reliable than keeping track of exactly the scripts you intend to run, and running them, without trying to compare state and guess.” Paul Stovell, Octopus Deploy http://docs.octopusdeploy.com/display/OD/SQL+Server+databases
- 25. @_AlexYates_ #SQLRelay “As soon as you have multiple changes on a single aspect of an object, ordering and the ability to detect which change needs to be made gets very complicated.”
- 26. @_AlexYates_ #SQLRelay “As soon as you have multiple changes on a single aspect of an object, ordering and the ability to detect which change needs to be made gets very complicated.” Gert Drapers, built DataDude https://blogs.msdn.microsoft.com/gertd/2009/06/05/declarative-database-development/
- 34. @_AlexYates_ #SQLRelay 11 2 Create view: kittenTrainersNrLdn Selects only: kittenTrainers.FullName Edit table: kittenTrainers Add column: AcceptsTigerCubs BIT Both work! Same changes, versioned and deployed two ways
- 36. @_AlexYates_ #SQLRelay 11 2 Create view: kittenTrainersNrLdn Selects only: kittenTrainers.FullName Edit table: kittenTrainers Add column: AcceptsTigerCubs BIT Both work! Same changes, versioned and deployed two ways
- 37. @_AlexYates_ #SQLRelay 11 Edit table: kittenTrainers Split column trainerFullName into trainerFirstName and trainerLastName But both suck. A tale of two work items… 2 Edit view: kittenTrainersNrLdn Add column: AcceptsTigerCubs
- 40. @_AlexYates_ #SQLRelay 0124_edit_view.sql 0125_edit_table.sql ALTER VIEW kittenTrainersNrLdn AS SELECT fullName, acceptsTigerCubs FROM kittenTrainers ALTER TABLE kittenTrainers *FUN WITH STRINGS* END ALTER VIEW kittenTrainersNrLdn AS SELECT firstName, lastName FROM kittenTrainers
- 41. @_AlexYates_ #SQLRelay ALTER TABLE kittenTrainers *FUN WITH STRINGS* END ALTER VIEW kittenTrainersNrLdn AS SELECT firstName, lastName FROM kittenTrainers 0124_edit_view.sql 0125_edit_table.sql ! ALTER VIEW kittenTrainersNrLdn AS SELECT fullName, acceptsTigerCubs FROM kittenTrainers
- 42. @_AlexYates_ #SQLRelay Conflicts easily missed Changes overwritten, hard to spot Order matters Last script wins The “winding path” problem How do you fix a bug that has been deployed to some environments but not others? The problem with migrations
- 43. @_AlexYates_ #SQLRelay V123 kittenTrainersNrLdn.sql CREATE VIEW kittenTrai… AS SELECT fullName FROM kittenTrainers
- 44. @_AlexYates_ #SQLRelay V124 kittenTrainersNrLdn.sql CREATE VIEW kittenTrai… AS SELECT fullName, acceptsTigerCubs FROM kittenTrainers V123 kittenTrainersNrLdn.sql CREATE VIEW kittenTrai… AS SELECT fullName FROM kittenTrainers
- 45. @_AlexYates_ #SQLRelay V125 kittenTrainersNrLdn.sql CREATE VIEW kittenTrai… AS SELECT firstName, lastName FROM kittenTrainers V124 kittenTrainersNrLdn.sql CREATE VIEW kittenTrai… AS SELECT fullName, acceptsTigerCubs FROM kittenTrainers V123 kittenTrainersNrLdn.sql CREATE VIEW kittenTrai… AS SELECT fullName FROM kittenTrainers
- 46. @_AlexYates_ #SQLRelay V125 kittenTrainersNrLdn.sql CREATE VIEW kittenTrai… AS SELECT firstName, lastName FROM kittenTrainers V124 kittenTrainersNrLdn.sql CREATE VIEW kittenTrai… AS SELECT fullName, acceptsTigerCubs FROM kittenTrainers V123 kittenTrainersNrLdn.sql CREATE VIEW kittenTrai… AS SELECT fullName FROM kittenTrainers !
- 48. @_AlexYates_ #SQLRelay REVISION 123 REVISION 124 kittenTrainers.sql CREATE TABLE kittenTrainers (fullName, acceptsTigerCubs) kittenTrainersNrLdn.sql CREATE VIEW kittenTrainersN… AS SELECT fullName FROM kittenTrainers kittenTrainers.sql CREATE TABLE kittenTrainers (firstName, lastName, acceptsTigetCubs) kittenTrainersNrLdn.sql CREATE VIEW kittenTrainersN… AS SELECT firstName, lastName, acceptsTigerCubs FROM kittenTrainers
- 49. @_AlexYates_ #SQLRelay Diff script: DROP COLUMN fullName ALTER TABLE kittenTrainers ADD FirstName NVARCHAR(50), LastName NVARCHAR(50) ALTER VIEW kittenTrainersNrLdn AS …
- 50. @_AlexYates_ #SQLRelay Diff script: DROP COLUMN fullName ALTER TABLE kittenTrainers ADD FirstName NVARCHAR(50), LastName NVARCHAR(50) ALTER VIEW kittenTrainersNrLdn AS … !
- 51. @_AlexYates_ #SQLRelay Script: DROP COLUMN fullName ALTER TABLE kittenTrai… ADD FirstName, LastName ALTER VIEW kittenTrain… AS … Need to understand your tool It should be obvious to you that your tool won’t work What is the Plan B / override? Because one day you’ll need it Test for data loss Automatically (naturally) The problem with state
- 52. @_AlexYates_ #SQLRelay So what is better? State MigrationsVS
- 53. @_AlexYates_ #SQLRelay State Easier (less control) Better for sprocs/functions Better for large/distributed teams Better for frequent changes Better for dependency nightmares Drift: rolled back Migrations More control (harder/needs discipline) Better for data migrations Better for small teams Better for infrequent changes Better for simple data stores Drift: ignored VS
- 54. @_AlexYates_ #SQLRelay State Easier (less control) Better for sprocs/functions Better for large/distributed teams Better for frequent changes Better for dependency nightmares Drift: rolled back Better for development Migrations More control (harder/needs discipline) Better for data migrations Better for small teams Better for infrequent changes Better for simple data stores Drift: ignored Better for automation VS
- 55. @_AlexYates_ #SQLRelay Pick appropriate tooling State DevArt Schema Compare DB Maestro Migrations DbUp Flyway Hybrid
- 57. @_AlexYates_ #SQLRelay How does SSDT work? Most scripts do not require manual scripting Manual scripting causes problems
- 58. @_AlexYates_ #SQLRelay How does SQL Source Control work? Most scripts do not require manual scripting Manual scripting causes problems Perhaps just these ones? So only write these ones
- 59. @_AlexYates_ #SQLRelay How does SSDT work? https://msdn.microsoft.com/en-US/library/hh272704(v=vs.103).aspx https://msdn.microsoft.com/en-us/library/jj889461(v=vs.103).aspx << RefactorLog Pre/Post-Deploy scripts >>
- 61. @_AlexYates_ #SQLRelay How does SQL Source Control work? (This diagram again) We still only need a few upgrade scripts
- 62. @_AlexYates_ #SQLRelay How does SQL Source Control work?
- 63. @_AlexYates_ #SQLRelay How does SQL Source Control work? https://documentation.red-gate.com/display/SOC5/How+migration+scripts+work c
- 65. @_AlexYates_ #SQLRelay State Easier (less control) Better for sprocs/functions Better for large/distributed teams Better for frequent changes Better for dependency nightmares Drift: rolled back Migrations More control (harder/needs discipline) Better for data migrations Better for small teams Better for infrequent changes Better for simple data stores Drift: ignored Better for sprocs/functions Better data migrations How does ReadyRoll work?
- 66. @_AlexYates_ #SQLRelay How does ReadyRoll work? Programmable objects (Views, stored procedures etc) V125 myproc.sql EXEC sp_rename 'table_foo', 'table_bar‘ Migrations (Tables, reference data etc)
- 67. @_AlexYates_ #SQLRelay How does ReadyRoll work? Programmable objects (Views, stored procedures etc) V125 myproc.sql EXEC sp_rename 'table_foo', 'table_bar‘ Migrations (Tables, reference data etc)
- 68. @_AlexYates_ #SQLRelay How does ReadyRoll work? Programmable objects (Views, stored procedures etc) V125 myproc.sql EXEC sp_rename 'table_foo', 'table_bar‘ Migrations (Tables, reference data etc) https://documentation.red-gate.com/display/RR1/Programmable+Objects
- 69. @_AlexYates_ #SQLRelay But haven’t we been doing hybrid for years?
- 75. @_AlexYates_ #SQLRelay Prod Test Dev S0 “Late migrations” S1 Prod Test Dev S0 “Early migrations”
- 76. @_AlexYates_ #SQLRelay Early vs Late • Test deploy script early • Easier to automate • Developers own deployments (typically) • Optimised deployment scripts (no winding path) • Easier to intervene • DBAs own deployments (typically)
- 79. @_AlexYates_ #SQLRelay “When making changes directly on production, you are making a decision that the delay due to poor cycle time is more expensive than the risk of making a mistake.”
- 80. @_AlexYates_ #SQLRelay “When making changes directly on production, you are making a decision that the delay due to poor cycle time is more expensive than the risk of making a mistake.” AlexYates, Built this slide
- 81. @_AlexYates_ #SQLRelay The bad stuff: • Accidental roll-backs (state) • Failed deployments (migrations) • Environment inconsistency (migrations)
- 82. @_AlexYates_ #SQLRelay Drift Strategies to help Improve cycle time Strict security policies Monitor drift (play with DDL triggers) Redgate DLM Dashboard (free) https://www.simple-talk.com/sql/database-administration/database-deployment-the-bits-database-version-drift/
- 83. @_AlexYates_ #SQLRelay Drift Strategies to help Improve cycle time Strict security policies Monitor drift (play with DDL triggers) Redgate DLM Dashboard (free) http://www.red-gate.com/products/dlm/dlm-dashboard/
- 85. @_AlexYates_ #SQLRelay Farm Credit Services of America (FCSA) • Standardised DLM processes • FCSA delivering much more efficiently • The FCSA model being rolled out at FCMA (sister org) • The team all have excellent CV’s
- 87. @_AlexYates_ #SQLRelay Siloed sparrows suck at DLM
- 88. @_AlexYates_ #SQLRelay Heated hippos are closed minded
- 89. @_AlexYates_ #SQLRelay State Easier (less control) Better for sprocs/functions Better for large/distributed teams Better for frequent changes Better for dependency nightmares Drift: rolled back Better for development Migrations More control (harder/needs discipline) Better for data migrations Better for small teams Better for infrequent changes Better for simple data stores Drift: ignored Better for automation VS Clever people consider options
- 90. @_AlexYates_ #SQLRelay State DevArt Schema Compare DB Maestro Migrations DbUp Flyway Hybrid Hybrid tools are awesomeTools are pretty good
- 91. @_AlexYates_ #SQLRelay Prod Test Dev S0 “Late migrations” S1 Prod Test Dev S0 “Early migrations” It’s a balance, not a choice
- 92. @_AlexYates_ #SQLRelay Hunt his smug face - make pain on it
- 93. @_AlexYates_ #SQLRelay This stuff makes a big difference http://www.codeaperture.io/2016/09/13/how-redgate-helped-define-our-process/
- 97. @_AlexYates_ #SQLRelay PREMIER SPONSOR GOLD SPONSORS SILVER SPONSORS BRONZE SPONSORS SUPPORTERS
- 98. @_AlexYates_ #SQLRelay Please give us your feedback: sqlrelay.co.uk/feedback Thank you
- 100. @_AlexYates_ #SQLRelay Image sources Author Source Information Chiltepinster Wikimedia Commons Mocking Bird Argument.jpg – Wikimedia Commons. This file is licensed under the Creative Commons Attribution-Share Alike 3.0 Unported license. Source on Wikimedia Commons: “Own work” Bit Boy Flickr The elephant in the room – Flickr. This file is licensed under the Creative Commons Attribution 2.0 Generic license. Nils Rinaldi Flickr Hippo fight 2/3 – Flickr. This file is licensed under the Creative Commons Attribution 2.0 Generic license. My own collection Taken by/property of Alex Yates Kitten, “There’s more than one way to skin a cat!” Memegenerator.net Memegenerator.net I don’t always edit database. Content designed to be shared and delivered with credit to memegenerator.net. Ctrl.Alt.Design ctrla.lt Social Media share icons
Editor's Notes
- This is Alex, he writes software to help you achieve DevOps for databases. This is Alex,
- Who has read a book?
- Show of hands… Who is a developer? Project manager? Do we have any DBAs? DBAs care about… NEXT SLIDE
- DBAs care about this stuff. Two buisness entities with different goals. It causes friction. NEXT SLIDE
- Sometimes OPS fail
- Sometimes OPS fail
- Sometimes OPS fail
- Sometimes OPS fail
- Sometimes OPS fail
- Sometimes OPS fail
- Sometimes OPS fail
- We’ve all done DevOps right. It looks like this. VCS, CI, RM. We are versioning, packaging and deploying our webapps. Maybe we’ve gone serverless? Everything is in source control and all our infrastructure is disposable. Right?
- We’ve all done DevOps right. It looks like this. VCS, CI, RM. We are versioning, packaging and deploying our webapps. Maybe we’ve gone serverless? Everything is in source control and all our infrastructure is disposable. Right?
- We’ve all done DevOps right. It looks like this. VCS, CI, RM. We are versioning, packaging and deploying our webapps. Maybe we’ve gone serverless? Everything is in source control and all our infrastructure is disposable. Right?
- What about databases? The persistent data the our businesses our built on? Schema changes vs existing data There is an odd relationship here between how you want the code to look and how you update prod. You can’t simply drop and replace the DB because you’ll lose your data. You have to create some sort of upgrade script. Twice as much code normally means twice as many errors and if the state you want and your way to get there don’t match, which is right? What is your source of truth? Without a clear idea of your source of truth – how is DevOps even possible? Reference data vs production data But while the database has existing data, not all of it is ‘production’ data in that sense. What about country codes? Reference data, lookup data, static data, the data that makes your system work. This data needs to get deployed with your schema changes. And you also need to think about how to transfer data in the other direction for testing. How do you test the latest dev build with production (or-production-like) data? Teamwork and testing The word DevOps refers to the problems associated with siloed Dev and Ops teams. Nowhere is this more apparent than in the land of the database? Is there anyone here who has never heard of any problems between Dev and DBA teams? But it goes further than that. With application source code we use source control, we invented distributed source control systems and we debate about the optimal branching strategies and strategies for implementing continuous integration. We’ve barely begun to have these conversations about databases. We barely have strategies for how to provision individual developers with their own sandboxes. Sometimes different developers work in different ways, some working off scripts and others working directly on the database. We need a better way of working together. And finally testing. Our problems with database source control and acquiring suitable test data make it hard for us to provision test database environments manually, let alone automatically. Database drift And all these problems result in this final point. In DevOps and Continuous Delivery we often talk about cycle time. How long would it take you to make a one line change, run it through your normal testing process and get it to production? If the cycle time for your database is measured in days, weeks or months (or years?) then when you hit a production issue you don’t have time to go back to your source code. The business is haemorrhaging money and the DBA will make a decision: What is more expensive, the cost of delaying the fix, or the risk of making that low risk change now and fixing the problem right away. It’s all well and good wagging your finger at people who choose to make hot-fixes directly on production, but until we sort out the cycle time problem, it won’t go away. Production drift is a symptom of poor DevOps or DLM strategy. And drift causes more problems: Environment inconsistencies undermine your tests and can cause failed deployments either because code clashes or because important fixes are accidentally rolled back. Drift and poor DevOps processes are a vicious circle that needs to be broken.
- For example, Paul Stovell (creator of Octopus Deploy) basically says the migrations approach is reliable and provides the functionality to handle the deployment whatever way works.
- For example, Paul Stovell (creator of Octopus Deploy) basically says the migrations approach is reliable and provides the functionality to handle the deployment whatever way works.
- Essentially, here is the challenge: get from one state to another, using some upgrade script. NEXT SLIDE…
- This leads some to think about database migrations in terms of the upgrade scripts… The source of truth is the upgrade script. Developers write upgrade scripts. They give these scripts to DBAs to review. The scripts get run in a specified order. A simple concept, and one that is easy to automate. It’s the sort of solution that you can hack together in an afternoon or you can use one of the open source frameworks like DbUp or Flyway. It’s pretty straightforward for users to understand how it all works. NEXT SLIDE…
- Other people still see the value/need to consider the state. This is important for repeatable testing etc. Migrations become a deployment detail because some would argue that scripting out every minor change is an overhead and opens up possibility of human error. This has the added benefit that it is easier to think declaratively about how specific objects should look. Arguably it is easier to handle source control, branching, merging and CI tasks this way. NEXT SLIDE…
- For example, Paul Stovell (creator of Octopus Deploy) basically says the migrations approach is reliable and provides the functionality to handle the deployment whatever way works.
- For example, Paul Stovell (creator of Octopus Deploy) basically says the migrations approach is reliable and provides the functionality to handle the deployment whatever way works.
- For example, Paul Stovell (creator of Octopus Deploy) basically says the migrations approach is reliable and provides the functionality to handle the deployment whatever way works.
- For example, Paul Stovell (creator of Octopus Deploy) basically says the migrations approach is reliable and provides the functionality to handle the deployment whatever way works.
- For example, Paul Stovell (creator of Octopus Deploy) basically says the migrations approach is reliable and provides the functionality to handle the deployment whatever way works.
- So what is better? Well, this is my attempt to summarise. The answer is neither is perfect. Generally, if the stuff on the left sounds more like your database, you’ll probably find a state based solution works better for you and visa verca. However, most people don’t live entirely on one side or the other. Let’s look at the tools available.
- So what is better? Well, this is my attempt to summarise. The answer is neither is perfect. Generally, if the stuff on the left sounds more like your database, you’ll probably find a state based solution works better for you and visa verca. However, most people don’t live entirely on one side or the other. Let’s look at the tools available.
- So what is better? Well, this is my attempt to summarise. The answer is neither is perfect. Generally, if the stuff on the left sounds more like your database, you’ll probably find a state based solution works better for you and visa verca. However, most people don’t live entirely on one side or the other. Let’s look at the tools available.
- So what is better? Well, this is my attempt to summarise. The answer is neither is perfect. Generally, if the stuff on the left sounds more like your database, you’ll probably find a state based solution works better for you and visa verca. However, most people don’t live entirely on one side or the other. Let’s look at the tools available.
- So what is better? Well, this is my attempt to summarise. The answer is neither is perfect. Generally, if the stuff on the left sounds more like your database, you’ll probably find a state based solution works better for you and visa verca. However, most people don’t live entirely on one side or the other. Let’s look at the tools available.
- So what is better? Well, this is my attempt to summarise. The answer is neither is perfect. Generally, if the stuff on the left sounds more like your database, you’ll probably find a state based solution works better for you and visa verca. However, most people don’t live entirely on one side or the other. Let’s look at the tools available.
- So what is better? Well, this is my attempt to summarise. The answer is neither is perfect. Generally, if the stuff on the left sounds more like your database, you’ll probably find a state based solution works better for you and visa verca. However, most people don’t live entirely on one side or the other. Let’s look at the tools available.
- I’m here to say neither solution is perfect. I’m going to explain it with an example. Let’s say my team has two tickets/work items. Each is picked up by a different developer.
- I’m here to say neither solution is perfect. I’m going to explain it with an example. Let’s say my team has two tickets/work items. Each is picked up by a different developer.
- I’m here to say neither solution is perfect. I’m going to explain it with an example. Let’s say my team has two tickets/work items. Each is picked up by a different developer.
- Let’s use a migrations approach first…
- Developer A alters the sproc like this…
- Developer A alters the sproc like this…
- Developer A alters the sproc like this…
- This brings me to the nub of the problem: With migrations you have to maintain many upgrade scripts. Strength: Complete control. Power and responsibility. Weakness: Challenge to manage. Winding path. So clearly migrations is broken – lets try state…
- Developer B adds their version
- Developer B adds their version
- Developer B adds their version
- Developer B adds their version
- But conflicts are a known problem and there is plenty of software to help with that. This is KDiff. Its free and open source. There are many other options. Many source control systems have equivalent functionality built in. Problem solved right? Ahem. Maybe. Let’s talk about that table rename…
- Here is the difference between the before and after state for the table and the sproc, with the differences highlighted in red. Now I’m going to use some sort of software tool to generate an upgrade script. Who can guess why this will fail? Anyone?
- That DROP TABLE could be a problem right? Diff tools that generate your upgrade scripts do not know the context for stuff. They see Table A on one side and table B on the other side and don’t know about the relationship between them. The don’t know how you got from one state to the other so they make it up. In this case by building a brand new table instead of renaming the existing table. If you cared about the data in table_foo you might not want to automate the deployment of this script. You can get similar issues with column re-names, table splits/merges, column splits/merges, adding not-null columns to tables with existing data, data migrations that won’t get picked up by schema diff tools etc. Also, when deployment scripts are generated badly they can have exceptionally poor performance. Often a skilled DBA will be able to significantly improve the performance of the upgrade script.
- That DROP TABLE could be a problem right? Diff tools that generate your upgrade scripts do not know the context for stuff. They see Table A on one side and table B on the other side and don’t know about the relationship between them. The don’t know how you got from one state to the other so they make it up. In this case by building a brand new table instead of renaming the existing table. If you cared about the data in table_foo you might not want to automate the deployment of this script. You can get similar issues with column re-names, table splits/merges, column splits/merges, adding not-null columns to tables with existing data, data migrations that won’t get picked up by schema diff tools etc. Also, when deployment scripts are generated badly they can have exceptionally poor performance. Often a skilled DBA will be able to significantly improve the performance of the upgrade script.
- So while the state based approach is arguably better for development and teamwork and for certain types of objects, it could have disastrous consequences when it goes wrong. If you are going to employ this approach you need to know the software you are using. (And by the way, you probably need to pay for it. Diff tools are more expensive and there aren’t any open source options. T’s worth investing in a good one for obvious reasons.) You need to be skilled at spotting when it will go wrong. You need to have some sort of review process and a plan B. This often means you still need a fair amount of manual steps in your deployment process, which is counter to the ideas at the root of DevOps.
- So what is better? Well, this is my attempt to summarise. The answer is neither is perfect. Generally, if the stuff on the left sounds more like your database, you’ll probably find a state based solution works better for you and visa verca. However, most people don’t live entirely on one side or the other. Let’s look at the tools available.
- So what is better? Well, this is my attempt to summarise. The answer is neither is perfect. Generally, if the stuff on the left sounds more like your database, you’ll probably find a state based solution works better for you and visa verca. However, most people don’t live entirely on one side or the other. Let’s look at the tools available.
- So what is better? Well, this is my attempt to summarise. The answer is neither is perfect. Generally, if the stuff on the left sounds more like your database, you’ll probably find a state based solution works better for you and visa verca. However, most people don’t live entirely on one side or the other. Let’s look at the tools available.
- So what is better? Well, this is my attempt to summarise. The answer is neither is perfect. Generally, if the stuff on the left sounds more like your database, you’ll probably find a state based solution works better for you and visa verca. However, most people don’t live entirely on one side or the other. Let’s look at the tools available.
- Once you figure this out, a lot of the rest of the problems kind of work themselves out. If you only use migration scripts for your tables you have less of them, they are easier to manage and there is less chance of a conflict. If you only use state for the objects that don’t touch the data you avoid the risk of migration scripts corrupting data or taking 8 hours to run.
- Once you figure this out, a lot of the rest of the problems kind of work themselves out. If you only use migration scripts for your tables you have less of them, they are easier to manage and there is less chance of a conflict. If you only use state for the objects that don’t touch the data you avoid the risk of migration scripts corrupting data or taking 8 hours to run.
- Once you figure this out, a lot of the rest of the problems kind of work themselves out. If you only use migration scripts for your tables you have less of them, they are easier to manage and there is less chance of a conflict. If you only use state for the objects that don’t touch the data you avoid the risk of migration scripts corrupting data or taking 8 hours to run.
- Once you figure this out, a lot of the rest of the problems kind of work themselves out. If you only use migration scripts for your tables you have less of them, they are easier to manage and there is less chance of a conflict. If you only use state for the objects that don’t touch the data you avoid the risk of migration scripts corrupting data or taking 8 hours to run.
- Once you figure this out, a lot of the rest of the problems kind of work themselves out. If you only use migration scripts for your tables you have less of them, they are easier to manage and there is less chance of a conflict. If you only use state for the objects that don’t touch the data you avoid the risk of migration scripts corrupting data or taking 8 hours to run.
- Once you figure this out, a lot of the rest of the problems kind of work themselves out. If you only use migration scripts for your tables you have less of them, they are easier to manage and there is less chance of a conflict. If you only use state for the objects that don’t touch the data you avoid the risk of migration scripts corrupting data or taking 8 hours to run.
- Once you figure this out, a lot of the rest of the problems kind of work themselves out. If you only use migration scripts for your tables you have less of them, they are easier to manage and there is less chance of a conflict. If you only use state for the objects that don’t touch the data you avoid the risk of migration scripts corrupting data or taking 8 hours to run.
- Once you figure this out, a lot of the rest of the problems kind of work themselves out. If you only use migration scripts for your tables you have less of them, they are easier to manage and there is less chance of a conflict. If you only use state for the objects that don’t touch the data you avoid the risk of migration scripts corrupting data or taking 8 hours to run.
- Once you figure this out, a lot of the rest of the problems kind of work themselves out. If you only use migration scripts for your tables you have less of them, they are easier to manage and there is less chance of a conflict. If you only use state for the objects that don’t touch the data you avoid the risk of migration scripts corrupting data or taking 8 hours to run.
- So what is better? Well, this is my attempt to summarise. The answer is neither is perfect. Generally, if the stuff on the left sounds more like your database, you’ll probably find a state based solution works better for you and visa verca. However, most people don’t live entirely on one side or the other. Let’s look at the tools available.
- Once you figure this out, a lot of the rest of the problems kind of work themselves out. If you only use migration scripts for your tables you have less of them, they are easier to manage and there is less chance of a conflict. If you only use state for the objects that don’t touch the data you avoid the risk of migration scripts corrupting data or taking 8 hours to run.
- Once you figure this out, a lot of the rest of the problems kind of work themselves out. If you only use migration scripts for your tables you have less of them, they are easier to manage and there is less chance of a conflict. If you only use state for the objects that don’t touch the data you avoid the risk of migration scripts corrupting data or taking 8 hours to run.
- Once you figure this out, a lot of the rest of the problems kind of work themselves out. If you only use migration scripts for your tables you have less of them, they are easier to manage and there is less chance of a conflict. If you only use state for the objects that don’t touch the data you avoid the risk of migration scripts corrupting data or taking 8 hours to run.
- So what is better? Well, this is my attempt to summarise. The answer is neither is perfect. Generally, if the stuff on the left sounds more like your database, you’ll probably find a state based solution works better for you and visa verca. However, most people don’t live entirely on one side or the other. Let’s look at the tools available.
- So what is better? Well, this is my attempt to summarise. The answer is neither is perfect. Generally, if the stuff on the left sounds more like your database, you’ll probably find a state based solution works better for you and visa verca. However, most people don’t live entirely on one side or the other. Let’s look at the tools available.
- So what is better? Well, this is my attempt to summarise. The answer is neither is perfect. Generally, if the stuff on the left sounds more like your database, you’ll probably find a state based solution works better for you and visa verca. However, most people don’t live entirely on one side or the other. Let’s look at the tools available.
- So what is better? Well, this is my attempt to summarise. The answer is neither is perfect. Generally, if the stuff on the left sounds more like your database, you’ll probably find a state based solution works better for you and visa verca. However, most people don’t live entirely on one side or the other. Let’s look at the tools available.
- So what is better? Well, this is my attempt to summarise. The answer is neither is perfect. Generally, if the stuff on the left sounds more like your database, you’ll probably find a state based solution works better for you and visa verca. However, most people don’t live entirely on one side or the other. Let’s look at the tools available.
- So what is better? Well, this is my attempt to summarise. The answer is neither is perfect. Generally, if the stuff on the left sounds more like your database, you’ll probably find a state based solution works better for you and visa verca. However, most people don’t live entirely on one side or the other. Let’s look at the tools available.
- So what is better? Well, this is my attempt to summarise. The answer is neither is perfect. Generally, if the stuff on the left sounds more like your database, you’ll probably find a state based solution works better for you and visa verca. However, most people don’t live entirely on one side or the other. Let’s look at the tools available.
- For example, Paul Stovell (creator of Octopus Deploy) basically says the migrations approach is reliable and provides the functionality to handle the deployment whatever way works.
- For example, Paul Stovell (creator of Octopus Deploy) basically says the migrations approach is reliable and provides the functionality to handle the deployment whatever way works.
- For example, Paul Stovell (creator of Octopus Deploy) basically says the migrations approach is reliable and provides the functionality to handle the deployment whatever way works.
- For example, Paul Stovell (creator of Octopus Deploy) basically says the migrations approach is reliable and provides the functionality to handle the deployment whatever way works.
- So what is better? Well, this is my attempt to summarise. The answer is neither is perfect. Generally, if the stuff on the left sounds more like your database, you’ll probably find a state based solution works better for you and visa verca. However, most people don’t live entirely on one side or the other. Let’s look at the tools available.
- So what is better? Well, this is my attempt to summarise. The answer is neither is perfect. Generally, if the stuff on the left sounds more like your database, you’ll probably find a state based solution works better for you and visa verca. However, most people don’t live entirely on one side or the other. Let’s look at the tools available.
- We’ve all done DevOps right. It looks like this. VCS, CI, RM. We are versioning, packaging and deploying our webapps. Maybe we’ve gone serverless? Everything is in source control and all our infrastructure is disposable. Right?
- For example, Paul Stovell (creator of Octopus Deploy) basically says the migrations approach is reliable and provides the functionality to handle the deployment whatever way works.
- For example, Paul Stovell (creator of Octopus Deploy) basically says the migrations approach is reliable and provides the functionality to handle the deployment whatever way works.
- So what is better? Well, this is my attempt to summarise. The answer is neither is perfect. Generally, if the stuff on the left sounds more like your database, you’ll probably find a state based solution works better for you and visa verca. However, most people don’t live entirely on one side or the other. Let’s look at the tools available.
- So what is better? Well, this is my attempt to summarise. The answer is neither is perfect. Generally, if the stuff on the left sounds more like your database, you’ll probably find a state based solution works better for you and visa verca. However, most people don’t live entirely on one side or the other. Let’s look at the tools available.
- So what is better? Well, this is my attempt to summarise. The answer is neither is perfect. Generally, if the stuff on the left sounds more like your database, you’ll probably find a state based solution works better for you and visa verca. However, most people don’t live entirely on one side or the other. Let’s look at the tools available.
- For example, Paul Stovell (creator of Octopus Deploy) basically says the migrations approach is reliable and provides the functionality to handle the deployment whatever way works.
- For example, Paul Stovell (creator of Octopus Deploy) basically says the migrations approach is reliable and provides the functionality to handle the deployment whatever way works.
- If no questions, Alex Y to kick of some Q+A by asking Alex T the following questions: - We talked about conflict resolution in programmable objects, but what about conflict resolution in migration scripts? I loved the demo, but demos are built on demo software and designed to make it all look so easy. What sort of problems am I going to run into in the real world? DevOps is about automation, and tools like ReadyRoll can help. But it’s also about Culture, Lean, Measurements and Sharing. Can you comment on how ReadyRoll supports DevOps in the wider sense?
- This is Alex, he writes software to help you achieve DevOps for databases. This is Alex,
- This is Alex, he writes software to help you achieve DevOps for databases. This is Alex,
- This is Alex, he writes software to help you achieve DevOps for databases. This is Alex,