Webinar: "DBMaestro: Database Enforced Change Management (DECM) tool"
Download as PPTX, PDF0 likes641 views
Emerasoft Srl, established in 2005 with locations in Turin and Rome, focuses on creating value for clients through productivity-enhancing solutions and collaboration. The document discusses the importance of database automation within continuous delivery, highlighting issues like mistrust in current version control processes and the need for effective communication between developers and database administrators. It emphasizes the critical role of databases in development processes and advocates for integrating version control and deployment automation to improve efficiency and reduce errors.
Webinar: "DBMaestro: Database Enforced Change Management (DECM) tool"
- 1. • Emerasoft srl • Mission • Vision • Market & Solutions Gian Giacomo Ermacora 26 marzo 2015
- 2. Chi siamo Data di nascita: 2005 Dove siamo: via Po, 1 – Torino via del Poggio Laurentino, 118 - Roma Creare valore per i nostri clienti implementando soluzioni che aumentano la produttività, facilitando la collaborazione. La nostra mission:
- 3. Ambiti Testing solutions Training: Emerasoft niversity
- 6. 6 In Database Automation We Trust! (Or do we?)
- 7. 7 • Over 150 Companies • Over 200 participants – Continuous Delivery is on the rise! – Database Automation meets mistrust… – Why? – What can be done? Recently Conducted DBmaestro Survey
- 8. 8 Recently Conducted DBmaestro Survey
- 9. 9 Why automation? • What is Continuous Delivery? • Why is it important? Automation
- 10. 10 Continuous Integration Continuous Delivery Continuous Deployment Automation is the Name of the Game…
- 11. 11 • A process, not a tool… • Focus on streamlining development – Developers integrate code into shared repository – Each check-in is verified – Automated builds – Automated tests – A feedback loop – High visibility • Easier & quicker to prevent and find problems, less back tracks => short integrations What is Continuous Integration?
- 12. 12 • Next step after continuous integration • Becoming lean, and even more Agile – Make sure each change is releasable • Develop-> build-> test-> move to staging-> acceptance test – Build a process to release with a push of a button • Deploy to production-> test production • Actual deployment to production is manually actuated => Ensure risk mitigation and high efficiency And Continuous Delivery?
- 13. 13 • Why is that happening? Continuous Delivery Moving Ahead!
- 14. 14 • Doing better with less • Reacting quickly to market needs • Getting ahead of competition • Just can’t wait 6 months for that next release… – Agile Development – Process Automation – DevOps Living in an Agile world…
- 15. Dealing with Risk Smaller and more focused changes are easier to manage (Agile…) Automation of repeating tasks lowers risk of (human) error Development and Operations should work in synergy (DevOps)
- 16. 16 • Rapid changes • Reacting quickly to market needs • Getting ahead of competition • Fewer changes backed out • Better collaboration • Fewer defects • Ultimately better service • Happy customers • Profitability Why Continuous Delivery?
- 17. 17 This is why!
- 18. 18 But…
- 19. 19 • Why not 100%? • 19% think it is impossible?? • What is so special about the database? Where is the gap?
- 20. 20 • The database holds your essential information • Any changes can impact the entire system • Need to be synchronized with other changes • Often overlooked Database is a Key Component
- 21. 21 • There is more to a database than SQL scripts – Schema structure – Code – Content and meta-content – Internal dependencies – … • Ensure that changes are not made without authorization • Ensure no out-of-process changes Reaching Inside the Database
- 22. 22 • Old adage but true • The database is often neglected and therefore can become the weakest link • Essential from a compliance and business point of view • Should be the strongest link The Weakest Link In a Chain
- 23. 23 • Why? Down from 81% to a HALF?
- 24. 24 • Silos exist… • Don’t always communicate effectively • Need to share knowledge • Need to follow same procedures & best practices Developers and DBAs
- 25. 25 • Mistrust… So why not move forward?
- 26. 26 Lets talk about Mistrust… “it was difficult to track who made a change to a database object and what change they made.” (working-around file based version control) “it took hours to get releases working. some changes were not documented and left out…” (manual and error prone releases) “We had multiple releases to production every day. That is one release a week with multiple follow up fixes, and yet more fixes” (code overrides, partial versions, wrong versions – all pushed to production) “We recently had a disaster - the script in the version control was not updated and when executed in production, ran the wrong revision. That cost tens of thousands of $” (an out-of-process update to QA that was not properly tracked)
- 27. 27 • Root Causes for issues: – Manual script based version control process – Deployment tools unaware of version control – No release automation red-flags…
- 28. 28 Mistrust in version control… Version Control Process (file based) Development Process Check-Out Script Modify Script Get updated Script from DB Check-In Script Compile Script in DB Debug Script in DB ? ? ? ? A A’
- 29. 29 Scripts & Version Control Challenges… – Code-overrides – Working on the wrong revisions – Scripts do not always find their way to the version control solution – Out of process updates go unnoticed – Hard to locate outdated update scripts Playing safe? what we really need: – The actual code of the object – The upgrade script – A roll-back script Scripts – Hard to test in their entirely (holistically) – Hard to test due to colliding dependencies – Need to run in a specific order… – Much harder to deal with project scope changes
- 30. 30 X 1.11.1.1 1.11.21.31.41.51.61.7 Mistrust in scripting automation… Int QA Stage Prod Database Deploy Script Environment Re-Base (due to defects) Dev Dev Dev Model 1.1 1.2 1.2 1.3 1.3 1.4 1.4 1.5 1.5 1.6 1.6 1.7 1.11.11.41.7 1.1 1.2 1.2 1.3 1.3 1.4 1.4 1.5 1.5 1.6 1.6 1.7 1.1 1.2 1.2 1.3 1.3 1.4 1.4 1.5 1.5 1.6 1.6 1.7 Out of Process Change X X X X X ? 1.1.1 X
- 31. 31 Scripts are static… Scripts, unless super sophisticated: – Unaware of changes made in the target environment – Time passed from their coding to the time they are run – Potentially overriding production hot-fixes or work done in parallel by another team Content changes are very hard to manage – Metadata & lookup content does not practically fit into the VC – In most cases they are simply not managed
- 32. 32 Gaining Trust! Coordinated ProcessTraceability Start in the Beginning No Out-of-Process Changes Impact Analysis Automation Task Based Development Well Defined Processes
- 33. 33 Version Control - One Enforced Process
- 34. 34 Dealing with challenges… Integrated Database Version Control process – Leverage proven version control best practices • Forcing check in & out for changes • Labels • etc.. – No code-overrides – Always working with the correct revision – All changes are documented – Always know who did what, when, why and from where – No out-of-process changes – Supporting structure, code and content No time spent on manual coding of the change scripts
- 35. 35 Bonus Points Task based development… – Correlate each database change with a change request • Task ID • Work Item • Trouble Ticket • CR • etc… …enables task based deployments – Partial deployments (a feature, a collection of bugs, etc…) – Scope changes easily synced between code and database
- 36. For deployment automation we need: Repeatability & Safety Using tools make sense …
- 37. 37 1.11.21.31.41.51.61.7 Build & Deploy On Demand * Int QA Stage Prod Database Deploy Script Environment* Execute the same script being executed at the Stage environment Re-Base (due to defects) Dev Dev Dev Model 1.1 1.2 1.2 1.3 1.3 1.4 1.4 1.5 1.5 1.6 1.6 1.7 1.1 1.4 1.4 1.7 1.1.1 1.7 1.1 1.1 1.11.41.7 File Based Version Control Out of Process Change 1.1.11.7 1.1.11.7
- 38. Using tools Test cases using compare & sync tools: An index exists in source (QA) but not in target (Production) What should we do? Add the index or not?
- 39. 39 Compare & Sync tools Safe to automate? Sure… (?)
- 40. Deployment Automation An index exists in Target (Production) but not in source (QA) What should we do? Drop the index or not?
- 41. 41 Compare & Sync tools Safe to automate? No. Requires manual inspection…
- 42. 42 Safe? Simple, right? NO! we are going to BREAK production without even knowing…
- 43. 43 Why break production??? A compare & sync tool: • Is unaware of any changes that occurred before the time it ran • Has no knowledge of changes that took place at the target environment • Does not leverage version control for more information • Unable to deal with conflicts & merges between different teams • Requires manual inspection • Requires detailed knowledge regarding each change as part of the process Mistrust AGAIN… So…no automation… as we fear automating problems into production and a major risk!!!
- 44. 44 We need to leverage version control into deployment decisions…
- 45. Safety Net For Deployment Automation Source vs. Target Action = No Action ≠ ? Source vs. Baseline Target vs. Baseline Action = = No Action ≠ = Deploy Changes = ≠ Protect Target ≠ ≠ Merge Changes You do not have all of the information With Baselines and 3 way analysis the unknown is now known Simple Compare & Sync Baseline aware Analysis
- 46. 46 Deploying Changes if Needed Development Baseline Previous Label / Production Golden Copy Production If we had the index in the baseline => we should take it down from production… (Deploy Change)
- 47. 47 Or Protecting Target Environment… Development Baseline Previous Label / Production Golden Copy Production BUT… If no index in baseline => we should protect the NEW index on production!!! (Protect Target)
- 49. 49 Conflict Resolving – Database Code
- 50. 50 Conflict Resolving – Meta Data/Content
- 52. 52 Impact Analysis! not Damage Control…
- 53. 53 Safety Net For Deployment Automation Database Safe Deployment Automation: • Leverages version control (baselines & previous revisions) • Has a flexible scope (deploy multi schema to single task or work item) • Can be run as a batch process (repeatable & consistent) • Integrates to ALM (labels, CRs, Continuous Integration & Delivery) • Deals with conflicts & merges to match code agility Can raise red flags to stop the line… if requires human intervention
- 54. 54 • Mistrust • Database Version control • Database Automation Awareness
- 55. Summary - What is DBmaestro TeamWork? • Database Enforced Change Management solution + Database version control + Enforce best practices + Plugs into the ALM (change request, tickets & work items) + Database merge & change impact analysis + Know who can do what, where, when & why • DevOps Solution for databases + Baseline aware deployment automation, rollback & recovery + Reduce database deployment issues + Plugs into release management & Continuous Delivery
- 56. Contenuti disponibili su: Canale slideshare di Emerasoft Canale Youtube Emerasoft www.emerasoft.com Q&A What’s next
- 57. Segui i nostri canali … www.emerasoft.com sales@emerasoft.com Emerasoft Srl via Po, 1 – 10124 Torino via del Poggio Laurentino, 118 – 00144 Roma T +39 011 0120370 T +39 06 87811323 F +39 011 3710371 Grazie… Contatti
Editor's Notes
- #2: Contenuto del webinar: panoramica generale dei criteri di selezione dei prodotti e successiva descrizione tecnica dei prodotti di test. Emerasoft si occupa di analizzare il mercato e di selezionare le migliori tecnologie per rispondere al meglio alle esigenze dei clienti.. Attraverso nuove metodologie e strumenti vuole favorire la crescita di modelli di Business e di Sviluppo più efficaci a costi e investimenti ridotti.
- #6: Some customer in Italy Market.