Comments
21 comments
-
What will happen to the existing SQL Source Control (SoC) and DLM Automation (DLMA) story with DlmDatabaseReleases etc?
Will that story still exist? What will happen for existing users who use SoC and (for example) the DLM Automation PS scripts and/or VSTS/Octopus plugins?
When my customers look at the options (typically SoC+dlma, RR, SSDT or open source script runner), it's the SoC + DLMA story that most want.
For reference, most of my customers are generally early in DevOps adoption, reasonable sized teams doing plenty of SQL Server dev, experiencing issues managing changes (hence moving to migrations-first strategy sounds like it will add complications) and wanting to move towards automated build/deploy but failing and in need of a simple solution. 100% automation isn't necessarily the top priority but simplifying dev processes, change management and mostly automated deploys is - they are happy to be lean and try to solve 80% of the issues with 20% of the effort and they like simple solutions. For these ppl SoC + DLMA is a good fit - and DLMA is a very important part of that.
Should I be steering them away from SoC/DLMA? -
Comment - in summary, most of my customers are probably currently at persona 2/3. Some aspire to be persona 4 but they aren't ready yet.
-
For these ppl SoC + DLMA is a good fit - and DLMA is a very important part of that.
Should I be steering them away from SoC/DLMA?
Thanks, Alex. You're suggesting that SQL Source Control +DLM Automation is a good fit for your customers and therefore that ReadyRoll isn't. What does ReadyRoll not have that SQL Source Control +DLM Automation does? -
In my experience, when a bunch of people have trialled SQL Source Control and ReadyRoll side by side, the majority like SQL Source Control better. They like it because:
- It's simpler (RR can feel more complicated and is often more of a headache to set up)
- SSMS integration
- Model approach is easier wrt branching and conflict resolution etc
Of course, the pain occurs at deployment time when the SQL compare generated script doesn't work, but the HTML diff report generated by DLM Automation is a wow moment that a lot of folks like. And frankly, the easy solution that solves 80% of deploy issues pretty quickly aligns well with a lean approach to improving dev processes. Get something that mostly works pretty quick and iterate from there - as long as you have a good feedback mechanism for when the process doesn't work and you need to intervene.
My view is that eventually, when ppl get to full devops, ReadyRoll is probably a better solution and the html report/any approval gates become less relevant/actual blockers on the process - but that's only possible once people have built up confident in tooling and, you know, thought about testing?
I do see SQL Source Control and DLM Automation as the natural first step for a lot of customers and my main Q is:
Will the existing SQL Source Control and DLM Automation story still exist? Is it going away? Do I need to stop recommending it? -
I have been asked about main issues ppl have with ReadyRoll:
- less intuitive (shadow DB, how to do the traditional commit, get latest, apply to my local DB, the dpeloyment package has various formats, which one should i chose? how do I automate that?)
- I got some error that I don't understand, what now?
- Migrations approach is fundamentally better for deployment but harder for dev
- Whoh, what's this Visual Studio thing? I'm a SQL guy, I don't understand VS projects. I just like plain simple sql scripts in source control
Admitedly, for folks coming from an SSDT background and who want to move to a migrations approach RR may be more intuitive. -
I do see SQL Source Control and DLM Automation as the natural first step for a lot of customers and my main Q is:
Will the existing SQL Source Control and DLM Automation story still exist? Is it going away? Do I need to stop recommending it?
Thanks Alex, for your detailed comments, and for your time today discussing it further.
To answer your question, you don't need to stop recommending the SQL Source Control/DLM Automation solution. The DLM A part of it will be renamed at some stage soon, and work is being done to integrate it with ReadyRoll but, as I understand it, the actual functionality will remain, so people's preferred workflows will be unaffected, and the story will still exist. Looking much further into the future, it may be that all of that functionality is available - for the state/model approach as well as the migrations approach - within one solution, but user experience and continuity will guide decisions and development.
Thanks again, and as discussed, I will come back to you soon to dig a little deeper!
-
For others, are there things you like/don't like about the offline SSDT model or the ReadyRoll migration model? Do those fit a more adaptable model of development if you could get your company to change some habits?
Do you prefer making changes in SSMS/SOS and summarizing them when you commit to VCS? Why does this work better? -
For others, are there things you like/don't like about the offline SSDT model or the ReadyRoll migration model? Do those fit a more adaptable model of development if you could get your company to change some habits?
Do you prefer making changes in SSMS/SOS and summarizing them when you commit to VCS? Why does this work better? -
I haven't implemented automated deployments for databases/data anywhere yet, but most people I have been involved with as an employee and a consultant are in the 1 and 2 categories and a few years from 3 and 4.
The offline SSDT model is pretty good for greenfield development but can be painful for getting legacy databases into source control and for ongoing development where you are fixing bugs and testing in a dev environment and then, at least the way I work, adding the code to the SSDT project. I would love an more integrated model where I have the database project in SSDT, but have a plug-in to SSMS/SOS/VS that allows me to connect an active database to the project. Essentially make SQL Source Control work with SSDT projects in a supported manner. -
I haven't used ReadyRoll, yet, but, as a developer, I value stuff like refactorings, goto definition, peek definition and such.
What I really would like was something that would give me the incremental changes to the database of ReadyRoll and the full current state of SSDT.
If I make a change on the "ReadyRoll side", it updates the "SSDT side". If I make a change on the "SSDT side", it updates the "ReadyRoll side", possibly, creating a new change set. -
Thanks, Jack, but a couple questions.
Why is the issue tough with SSDT? Because you need a comparison to get changes from the live dev db to the model ? Is is the offline model that's cumbersome?
Also, why do you need SSDT projects with SQL Source Control? Are the SQL Source Control projects not enough or are you trying to maintain history? -
Paulo,
The schema model still exists in a Ready Roll project. Is there something else you need to see? If you make a change and import a migration script, the changes are also imported to the schema model.
Not arguing, but trying to understand and get you to express the details. I think RR has most of what is good, but there are some holes. I don't want to influence your response with my bias or view of the issues.
-
100% automation isn't necessarily the top priority but simplifying dev processes, change management and mostly automated deploys is - they are happy to be lean and try to solve 80% of the issues with 20% of the effort and they like simple solutions. For these ppl SoC + DLMA is a good fit - and DLMA is a very important part of that.
I completely agree with this sentence. That approach is, IMHO, lean, quick, useful, simple and really clear. So I would love to keep using those two things combined.
-
way0utwest wrote: »Paulo,
The schema model still exists in a Ready Roll project. Is there something else you need to see? If you make a change and import a migration script, the changes are also imported to the schema model.
Not arguing, but trying to understand and get you to express the details. I think RR has most of what is good, but there are some holes. I don't want to influence your response with my bias or view of the issues.
I need the get a closer look at ReadyRoll. -
There's a webinar about Database DevOps using ReadyRoll and the new VSTS extension (which also works with TFS) for CI/CD tomorrow Tues Nov 28th at noon ET - https://attendee.gotowebinar.com/register/817288270091583491?source=FORG.
-
Thanks Stephanie!
-
way0utwest wrote: »Thanks, Jack, but a couple questions.
Why is the issue tough with SSDT? Because you need a comparison to get changes from the live dev db to the model ? Is is the offline model that's cumbersome?
Also, why do you need SSDT projects with SQL Source Control? Are the SQL Source Control projects not enough or are you trying to maintain history?
Steve, sorry for the delayed response. Busy over the holiday.
Yes, the comparison between live DB and the project model is a step I'd prefer not to have to do. With creating an SSDT project from a legacy database, I have always seen errors that keep the project from successful building because of past development practices (not removing unused objects, etc...) that the effort to cleanup the project so it will be build is very time-consuming and painful.
So what is missing from SQL Source Control are database level settings/configs, like collation, recovery model, ANSI settings, Isolation level. Database projects include all these settings and since collation, isolation level, and ANSI settings can affect how code works and performs, I see them as things that need to be under source control. I'm sure I could add them to a SQL Source Control project, but I get that by default with SSDT. I also like the "build" functionality in SSDT which, to my knowledge, SQL Source Control doesn't do. With SQL Source Control, I LOVE the integration into SSMS and the direct link to an active database. I just want both. -
Thanks, Jack. I think the db level and instance level settings are items that are needed. Hopefully we'll get them added soon.
-
Personas #1 to #4 kind of represents the path to Database DevOps (stages: source control, ci, cd).
While looking to a tool to incorporate in the pipeline (or development process) to me it's important that my decision about a tool in have the less impact possible in the different stages of my process/pipeline.
And since our needs and knowledge change/evolves over time the cost of changing tool, technical speaking, should be the lowest possible. For this reason I like the "plug and play" idea (VSTS is a good example): the different tools (SoC, RR, DLM Automation) for the different stages (sc, ci, cd) should be always compatible independently of the combination that I need.
Regards,
Eduardo Piairo
-
I will chime in for the masses. Whatever you do, don't screw with basic Source Control functionality and ease-of-use!
-
Hello,
I see personas #1 to #4 as a path to Database DevOps (stages: source control, ci, cd).
So I would like that my decision in a stage have the less impact possible in the next stage. Example: If I start with SQL Source Control and then want to automate my deployment does that mean that I have to change to Ready Roll?
My vision is more "database change pipeline" oriented: doesn't matter the tool that I will use for doing source control because i will have full support for automate my validation and delivery process.
And since our needs and knowledge change/evolves over time the cost of changing tool, technical speaking, should be the lowest possible. For this reason I like the "plug and play" idea: the different tools (SoC, RR, DLM Automation) for the different stages (sc, ci, cd) should be always compatible independently of the combination that I need.
Regards,
Eduardo Piairo
Add comment
Please sign in to leave a comment.
The teams at Redgate HQ have been working on developments to our various versioning and automation tools, and we’ve just finalised a review that resulted in a slight change of strategy for 2018 so I wanted to update you.
My last update explained that we feel we have too many tools to solve similar problems around versioning and automation, and that we recognise the need to simplify our offering to make it easier for customers to navigate and use. We were planning to combine SQL Source Control, ReadyRoll and DLM Automation under one umbrella, to provide a single solution for all versioning and automation use cases.
A few months into the development work and marketing planning towards this goal, it was becoming clear that there were simply too many variables in use cases for these tools and we can’t sensibly satisfy them all with one product, so we took a step back, analysed the use cases, and revised our plans.
What we decided, and how
We’ve decided to target the versioning & automation market with two products.
SQL Source Control will continue to exist for the foreseeable future. This product will cater for users in the early stages of their DevOps journey who are concerned with version history or growing teams and not really thinking about automation just yet.
ReadyRoll and DLM Automation will be combined into a single product (name TBC). This product will cater for more advanced users who are looking to automate their deployment process.
Our thinking about the direction that Redgate’s versioning & automation products need to take over the next couple of years has been strongly informed by user analysis which grouped users under 4 key personas.
Persona #1 – change history
“I need to put a record of development changes into Source Control so I know who changed what and when.”
Persona #2 – team process & collaboration
“I need a better way to manage my growing dev team so we don’t keep stepping on each other’s toes and we can all get our changes to a test environment.”
Persona #3 – agile & automating
“We’re releasing changes more and more frequently. I want to automate our release processes so that they’re repeatable.”
Persona #4 – full database DevOps
“DevOps is the way forward for us. We want to release our changes as fast and as often as possible with minimal risk.”
What are your thoughts?
The work we’re now doing is to ensure that SQL Source Control continues to meet the needs of personas 1 and 2, and the automation product arising from the combination of ReadyRoll and DLM Automation meets the needs of personas 3 and 4, across both SSMS and Visual Studio.
I’m keen to hear thoughts on this, particularly if you or a client fit exactly into one of the personas, and feel that messaging around these personas would help to know which tools and processes to use, but also if you or a client don’t fit easily into one of these personas and would be happy to tell me more about your processes.
Please share your comments below, or email me directly and I’ll set up a time for us to talk over the phone.
Many thanks
Mary
Mary.robbins@red-gate.com