Up next in 10
Deployments aren’t enough – databases deserve a development process | .NET Conference 2025
Jun 19, 2025
How quickly can you take your database and examine its code? Database-as-code is not a new concept, but all too often we focus only on being able to apply changes to the database instead of having a development process that ensures that we’re making good database changes. A more wholistic development process offers early warnings of antipatterns via code analysis and increases our confidence even on mature databases with deployment “practice runs” and unit tests. In this session we’ll discuss the components of a database development cycle through the lens of Microsoft. Build.Sql projects and what capabilities we should expect to deliver database object updates easily and more reliably.
Conference Website: https://dotnetconference.com
📺 CSharp TV - Dev Streaming Destination http://csharp.tv
🌎 C# Corner - Community of Software and Data Developers https://www.c-sharpcorner.com
#CSharpTV #CSharpCorner #LiveShow #dotNet #DotNetConf2025
Show More Show Less View Video Transcript
0:00
thanks everybody for for joining or tuning in later to the recording But I'm Drew Squire Kabala as Simon introduced I
0:07
work at Microsoft as a program manager which means I work in in the product space product engineering group And I
0:14
generally focus on SQL DevOps You'll sometimes see me talk about SQL projects
0:20
but I'm going to give you a heads up right now that that is not what we're going to start talking about today When
0:25
I talk about deployments aren't enough and that databases deserve a development
0:30
process this is because sometimes people say I already have my development
0:36
process for my application and the database doesn't really fit into it but I'm not going to move to to SQL projects
0:43
How do how do I how do I get there in terms of having a development process from a database and that's what we're
0:49
going to focus on today So just just a kind of a a quick warning for folks that usually hear me talk about SQL projects
0:55
Um don't don't get too alarmed if we don't jump right into those But with talking about development
1:03
processes this does mean that we have to start by looking at DevOps holistically
1:08
because DevOps is not new Um the new stuff is AI DevOps has been around for a
1:15
while but it allows us to build better by using a couple different foundational
1:21
components These are always going to be a little bit different depending on who you ask but today when we talk about
1:27
databases and the development process that they should have we're going to use the four of culture the product process
1:35
and then tools The culture are the people that are involved So this is you
1:41
and this is the other people that you may or may not work with Um maybe maybe
1:47
they eventually get pieces of your application for later deployments or
1:53
maybe they're eventually responsible for uptime Maybe you are a developer or maybe you're someone that is responsible
2:00
for those components But everyone that's involved in an application is responsible for keeping that
2:06
communication and collaboration healthy as a part of the culture This is the
2:11
first thing that you have to have to get to efficient development Efficient
2:16
development and then the delivery of this that product is the usual bar that we're shooting for when
2:24
we have DevOps We don't just wake up one morning and be like I feel like doing DevOps We wake up one morning and we
2:30
realize I'm not able to deliver the value for the company that I want this
2:37
application to have Either it's too slow getting out the door or we're getting the requirements wrong And so you end up
2:43
having to have a foundational pillar of the product needs to be delivering value and doing so efficiently as a part of
2:50
DevOps Now the last two get a little bit more tactical and this is what makes
2:56
things easier to talk about The next one is the process that we have to have There needs to be a process as a part of
3:02
development Now for things like C development net development there are
3:08
well-known processes I know there was at least one other talk earlier today around how to get to good architectures
3:15
and what things you can do to have testdriven design Um so you have a set
3:22
of actions that you make a part of your development process so that you end up with consistent outcomes and ideally
3:29
these consistent outcomes are the product gets better and is more valuable But usually to do these
3:37
processes you need tools that enable them And at the end of the day um as
3:42
somebody that works on developer tools I'm going to tell you that they ultimately are one of the least
3:47
important things because you need the culture you need the focus on the product and you need agreement on a
3:53
process But the tools do enable you to end up with a DevOps cycle And this
4:00
means that we want to be able to get to a point where the database gets a
4:06
development process Your .NET app has a development process
4:12
but the database itself also should What do I mean by your application has a development process
4:18
well I'm going to assume that it's a C# project Um but I mean if you're working really with any language you generally
4:26
have some kind of life cycle really truncated down You have a build and
4:31
deployment step Now these usually get broken up a little bit more to where there's a culture component where
4:37
there's an agreement between different teams of the level of test coverage as a
4:43
part of build or how often you deploy and then the communication that has the
4:49
the conversations throughout all of that But then the product itself that project
4:55
that you're building the the the requirements for it the the timing of
5:02
the delivery to meet certain deadlines all of those things are really important to have
5:07
aligned And then the process obviously when you do a C project and you check it
5:15
into source control there's the common continuous integration or CI checks If
5:21
you create a new repository in a place like GitHub or GitLab there's a template for you even that will set up a pipeline
5:28
that does net build and net test to make sure that what you're checking into
5:34
source control is good And then you have additional processes that you can set up as a part of the deployment And then
5:41
finally what are the tools that help you do all this now frankly you might get to this point
5:48
and you're like "Wow he's kind of managing to make development sound kind of boring." Like I really just want to
5:54
build and ship Like isn't that what we're all doing as developers like I just want to get to a point where I'm
6:00
making something it's valuable and it magically goes out the door Yes we do We
6:06
do want to be building and shipping None of these DevOps foundational principles should be getting in the way they should
6:13
be making it so that you can do this faster ultimately and with more
6:18
consistency So in the spirit of just building and shipping um I've built
6:23
something I haven't actually shipped it because it's a little bit of a prototype Okay actually it's a tutorial but I've
6:29
started building an EF Core app This is the Razer Pages app
6:35
that looks super super fancy Um it's just a student list It's got a bunch of
6:42
different enrollment information It's not all that fulfilling Um so I you know
6:48
started designing my models in the C code Like I promised you earlier we're
6:54
we're not starting with SQL projects I'm just developing how in this case if I were an EF Core developer I know how to
7:01
best get things moving As you can tell from this very rudimentary example I
7:07
haven't gotten very far and I haven't gotten to a point where I can really embrace all of the best practices that
7:14
come with the EF Core estate That doesn't mean that the
7:19
database should just languish Um that database should also be
7:26
a part of the development process as I move towards establishing best practices What I mean by this is in addition to
7:34
running a pipeline that
7:42
does net build net test on checkin I should also have another workflow that's
7:49
keeping an eye on main both on pushes and pull requests that does things for
7:54
my database Why why why am I maybe maybe would I care about what's going into my
8:00
database my student example uh the student model here this is going to create a student table in the database
8:07
And there's going to be some string fields for last name first name and middle name
8:13
This looks fine at first glance although maybe a little little cludgy but we
8:20
can't quite put our finger on it depending on how seasoned you are of what's what's wrong with this model from
8:27
the databases perspective If I know C# really well I can start picking out things that I would want to add But from
8:34
the database perspective I'm not even looking at SQL code I may not even need to know it But something in the process
8:42
needs to be helping me figure out what's going to go wrong here Like where are
8:47
the hidden pitfalls and traps i don't want to touch any SQL code to figure
8:53
this out I want this to be a part of my development process What I'm going to do now is step back and show you into
9:01
another CI pipeline in addition to this.NET net one that takes a look at
9:06
what will happen with the SQL code and give me automated feedback on it kind of
9:12
in real time or immediately or in this case um right now on main the last time
9:19
my my SQL development feedback pipeline ran it failed um it's setting itself to
9:25
fail because it's finding an abundance of warnings no code analysis errors and
9:31
we'll we'll get into what all these things mean in a moment But it is finding enough warnings that it's hit my
9:37
threshold to make it fail So code analysis results over
9:42
threshold And the results that it's presenting with me now is I've hit a
9:48
couple instances where I have max length character fields going into my database
9:55
SQL Server does a pretty good job of taking care of if you have a really long
10:01
string field not putting the data off row So this is not necessarily a huge
10:06
performance red flag where everything is going to go up in flames immediately I'm not I'm not suggesting that Um what I am
10:13
suggesting is that you're setting yourself up for bad design practices
10:18
down the road if we end up shipping this out as is what what kinds of things can happen
10:25
um and I know some of you are going to be like that would never happen and then you'll see it a month later But what if
10:30
what if we don't use this middle name field we use first name and last name but we leave middle name empty We don't
10:37
we don't tie it into our application but now we have this big old juicy varax
10:44
field sitting in the student table ready to use and a month from now someone's like
10:50
"We need to have a profile name field on the student records immediately We don't have any time to wait We can't wait for
10:56
a database deployment Just make it happen." And you're like "Hm we have this really big unused field
11:05
It could be anything We didn't really specify data size or anything It's super flexible We'll we'll use that It doesn't
11:11
matter that it says middle name in the database No one's ever going to do any kind of analytics on this They don't
11:17
need to worry about it we'll just use a million view You don't want to leave these kinds of strange structures just
11:24
hanging out in your database if you can clean it up before it gets further down the development pipeline So this is the
11:30
feedback that I'm getting on my database How did I get it how did I get it
11:37
well the SQL dev feedback pipeline is pretty hefty and I will drop the uh a
11:44
gist link to this uh YAML file in in the chat in just a moment so you can peel
11:50
through it on your own time as well But what this workflow does is in addition
11:56
to being able to be um run on demand as well as watching the the main branch
12:03
there it's going to set aside a folder for Ktoso DB So this is not part of my
12:11
code I have just the EF core app all kind of as a mono repo right now in my
12:17
early state but there's no other SQL files in my repository perpetually
12:24
However temporarily we're going to generate this so that we can work with it behind the scenes We'll set it up as
12:32
a DevOps process and then walk away from it and just benefit from it as our ongoing de development continues
12:40
Now the code analysis job I'm passing it a connection string and this connection string is localhost
12:47
Now this is not the container running on my machine This is a SQL server container
12:54
that's going to run inside the pipeline I don't I don't need to have a
13:01
additional SQL instance provisioned for me somewhere else I just need a development instance that's going to
13:06
live for the lifetime of this pipeline And I've got a password that's stored in in in a secret for the
13:13
pipeline but that's just kind of keeping an extra layer of security And the reason why I have this container is that
13:21
it's allowing me to tie in the same EF core
13:26
migrations that I would be using as a part of my local development to test like we had the the the student
13:33
interface loaded in the browser earlier But now I'm able to do this in a pipeline I'm not having to make my
13:40
development process more complex I can continue focusing on just I want to
13:46
build and ship But now I'm able to start thinking about
13:53
the SQL in terms of is it valid and is it good and the way I get there is after
14:02
installing a couple dependencies So these are .NET tools then the net ef tool and Microsoft.SSQL
14:10
package I'm able to start setting up a SQL project This isn't something that I
14:16
have to develop with but this is something that we're going to use as a part of the files that come out of the
14:23
database Now the the database itself is getting
14:28
created So I've created the container and now I'm going to do a create
14:34
database statement on that container So this is all these setup steps that I would have to do
14:41
locally I'm going to set up as a part of a pipeline that can continually run And now whenever this pipeline runs it's
14:49
going to apply my EF database update Now if I were using Node.js JS I could do
14:55
the hibernate migrations Or if I already have
15:00
um Flyway set up I could use Flyway um uh schema changes applied on this
15:07
container in the pipeline I don't have to change all of that to be able to benefit from running code analysis on my
15:15
objects The reason that is is getting the objects as scripts is a single SQL
15:23
package command Now the SQL package CLI was a net tool that we installed earlier
15:29
in the pipeline And when I we run extract with this CLI and say I want my
15:35
extract target to be schema object type this reads all of the objects out of the
15:40
database so just their definitions and writes all of them to individual SQL files This in itself can be really nice
15:47
in terms of being able to give these SQL files to someone that speaks SQL instead
15:53
of C They'd be able to see that outcome This in this very moment is not about
15:59
helping those people This is just about giving me the developer feedback So I'm
16:04
going to take these SQL files as well as I created a SQL prod So this creates
16:13
that container or that logical project around all of those individual SQL
16:19
files and now I'm running net build on the SQL project So this is a little bit
16:26
of what I already know about hey if I want to build a project I run net build but now I'm leveraging SQL projects as a
16:33
part of this development process here and I'm turning code analysis on I
16:39
haven't had to open it up in Visual Studio or VS Code and change any settings This is all being automated for
16:46
me I create it once and then it'll run every time I continue to make application changes
16:53
So if I were to run if I were to
17:00
run this locally now I I don't need to do this but if I were to run this
17:05
locally let's say I've got a SQL project and the files for that database
17:15
If I were to do a net build that a little
17:24
bigger and I've got code analysis turned on in the properties of this project but we're passing that
17:30
in I get first the validation of all of
17:35
the objects So it's making sure that there haven't managed to be any
17:41
uh syntax errors or um missed references Now EF Core usually handles all of this
17:49
for me EF Core is excellent at this Not every application framework is Maybe you're using Dapper or um you're you're
17:58
making the calls um individually through another another framework or you're using a SQL client driver However you're
18:04
doing it this is adding that extra layer of protection of making sure that there's nothing
18:11
um malignant going into the database Not not intentionally malignant but just accidentally oh I have a view that has a
18:18
column that doesn't exist You could find that out at runtime or you could find that out as a part of your CI Now the
18:25
second part of this net build So the is it valid is validating all those
18:31
references But the is it good is always the hard question because is it good is
18:38
kind of the one of those beauty is in the eye of the beholder questions where
18:43
the the the SQL that you write could be fine Um but your
18:49
organization could have certain concerns or there could be certain best practices that you're not familiar with I
18:57
certainly don't know all of the best practices I've been out of active daily
19:03
development long enough that it slips right by me But this is where code analysis can help me out Now out of the
19:10
box if I were just just to run a SQL project build
19:16
um net build run SQL code analysis there's about 14 rules for SQL code
19:22
analysis that come as as um that that check for some of the really egregious
19:28
things um in terms of select star or some really naming paradigms that can
19:35
cause you problems However you can add package references that bring in additional rules The
19:43
eagle-eyed viewers might have noticed that after I created the new SQL prod
19:48
with net new I went into that folder and I added a package
19:55
The number of community members have written a ton like hundreds of code
20:00
analysis rules that catch a bunch of different scenarios and those are uh excellent and I recommend that as you
20:07
start to check out code analysis you also check out those packages But for the instance of this this demo what I
20:14
wanted to also point out is that if your organization has specific rules it can be excruciatingly easy to bring in your
20:23
own custom rules And in this case I built a single rule just to avoid max
20:28
length characters Now this point is usually where I lose core SQL developers that
20:36
love writing SQL because to write code analysis rules this is extensibility
20:41
that's a part of SQL projects that's all based on.net So you get to use C to
20:48
write custom rules The SQL projects templates include a net
20:56
new SQL project code analysis that you can start from And I've got to be honest when you think about how can AI help me
21:04
dabbling into places where you're not super familiar with um the the API space
21:12
or some of the the patterns of those those uh extensibility things is a great
21:19
use case for it because I took that template and I passed it over to an
21:25
agent I use I used GitHub agent and I said "Hey I want to make this rule
21:30
instead of the template which is checking for weight for delay I want to have it check table columns for max
21:36
length characters." And it it nailed it It nailed getting the rule constructed
21:43
Now what these SQL code analysis rule um classes are is they're a specific class
21:50
for the rule that you want and you assign it the ID and kind of the name or the description and then you have it
21:59
define a function for how it should analyze the SQL code Now you don't need
22:05
to be thinking about you know writing reax to parse SQL code you don't need to
22:12
learn all of the intricacies of the TSQL language because what it is using is it's using um the object model the same
22:20
object model that's a part of the net build where it's able to validate those relationships So you end up with
22:26
statements like for column in visitor column and then checking if it's a
22:32
maximum length column So you're not having to parse out the the SQL syntax
22:38
but you're able to use the same net constructs that you know Building and
22:44
packaging this gets me that package that ultimately becomes a package reference
22:51
on my SQL project because in that pipeline I added
22:56
it to my SQL project So when I think about is it good our code analysis
23:02
pipeline can give us a range of feedback whether it's the outofthe-box rules
23:08
rules written by the community and then over time within my organization if we find patterns that we want to keep an
23:15
eye for we're able to use custom rules to add those on as well All of this has
23:21
been fun and good and it has told me in main I have some max length columns We
23:26
should really take care of this and let's just get that done The good news
23:33
is I've already made the changes I've set some string lengths even through an
23:38
error message on first name Um I went ahead and shortened middle name even
23:43
though we're not necessarily using it in the interface yet just to set us up for success And I'll go ahead and push that
23:52
out And I'm going to open up a pull
23:58
request and get that going Now because this pipeline stands up a container runs
24:03
EF migrations um and then creates the SQL project Um standing up the container takes about a
24:10
minute a minute 10 EF migrations another 10 seconds Creating the SQL project another 15 seconds So it takes about 2
24:18
minutes for the checks to run Our .NET build is real real quick because our
24:23
project is not super large So while I let that go I'm going
24:29
to touch back on why why do we care about checking SQL code quality kind of
24:35
at check-in time I'm I'm not I'm not the person necessarily that sets the bar on
24:41
what the database should look like I might have to talk to someone that's
24:47
responsible for the database It could be someone else Um so this becomes part of your culture too to have that
24:53
conversation about does the does the the database need to look
25:01
differently as it gets down the road and then the terminology of shifting it left for bringing that in as part of the
25:08
culture that you have Now the the the question that came up um
25:14
in the in the YouTube chat from Roit asks "What are the key differences between a traditional database
25:20
deployment and a true database development process?" I love this question because at this moment we're
25:26
seeing where we have a database development process starting to take shape Now the approach that we're taking
25:34
in this demo is that using EF Core is
25:39
great like they're I'm not taking issue with using EF Core at all That
25:44
application development is is good and using migrations to find out what the
25:49
database should look like is that next step Um the de database development
25:56
process becomes the ability for us to bring inspection of the impact on the
26:05
database further left or earlier in the development process so that when I open
26:11
up a pull request I'm starting to find out what my impact will be on the
26:17
database earlier and earlier And I'm not even looking at yet what the deployment
26:23
impact will be I'm just looking at overall what are the SQL objects and are
26:30
they of the same quality or am I thinking about them in the same way that I think about my net code You might have
26:38
a code llinter fornet or you might be thinking about unit tests These same
26:43
kinds of thought processes that's what gets us to a true database development process regardless of how you're
26:50
creating those SQL objects if they're coming out of um EF Core models like
26:55
that still doesn't absolve you of having a database development process You can still introduce CI as a part of that
27:02
database development process the uh question from Scott about how do
27:09
you recommend running practice runs of deployments in CI/CD pipelines especially for mature complex databases
27:16
is an amazing question that I will get to in like three minutes when we look at how can we look at what a deployment
27:23
will look like without hurting anything kind of early on and then I see a
27:31
question from um Sakshi Sharma about common database anni patterns that can
27:36
be caught early through code analysis Um I'm I'm going to give a little bit of a
27:42
non-answer Um but also answer the the pro the problem that makes this
27:49
a little bit of a non-answer is that it can be just about anything in the database that is an
27:55
anti-attern Almost all of them can be caught because the code analysis rules
28:00
are extensible Now if I check out the rules that come out of the
28:09
box they're generally grouped as design issues naming issues and performance
28:14
issues which is really cool that we can catch even things that
28:20
um have to do with the the comparison of things having different data types
28:26
potentially causing a problem So if you have a wear statement where something on one side of the equality is an integer
28:34
and something on the other side is a string and you would have a cast involved You can catch this with code analysis Um there there are um usages of
28:43
at add identity um is the the scope identity one right here where it can
28:48
actually be shared across multiple database sessions happening at one time These are not things that I just keep
28:54
memorized in the backlog of my head when I'm focusing on you know if creating my
29:00
model views and controllers like this is SQL these are SQL problems that I need someone else to catch but if I use code
29:07
analysis then I can bring it back in So the the uh the usage of code analysis
29:14
rules really can catch a ton of anti-atterns but they can kind of
29:19
cascade both from just like this design problem that I used for max length characters all the way to um performance
29:27
level things Um but I do want to check out
29:34
my pull request for CI on changing the length of those fields I'll see that
29:43
my SQL dev feedback is now all green I don't have any code analysis errors or
29:50
warnings And I have two artifacts as a part of this
29:55
pipeline because sometimes when I'm doing development I'm making changes like this
30:02
This is where I have to have a conversation with someone or I know that there's someone else on my team that
30:07
knows this database better than me that's going to want to check it out and this can help them do that What What are
30:14
these two artifacts you ask further down in
30:20
our pipeline we've evaluated the code analysis output The code analysis output
30:27
comes as XML and I have a little PowerShell script that will be the other gist that I share with you today that
30:34
takes that XML parses it to markdown and then passes it to that GitHub summary
30:39
which kind of gives us that big flashing lights of what have we done right or wrong
30:45
Now the artifacts that we output The first one is the DACP pack A DAC pack in
30:53
itself can be kind of tough to use because it's a zip folder with a
30:58
different file extension and inside of it is a bunch of XML It's that compiled database model So unless you are
31:05
planning to use the SQL package CLI with it you might not have an immediate use for it But because it does capture the
31:14
database state the object definitions at this point in time it is such a great
31:19
thing to archive because then you can do comparisons between you know we had
31:25
version 1.1 go out and then 1.3 and we've seen some really weird
31:31
changes One of the easiest ways to find out what has changed is to you do a
31:36
schema comparison on DACA packs you don't have to constantly be working with
31:41
deck packs or constantly be doing schema comparisons to be able to pull this off the shelf and do that ad hoc um
31:48
comparison Now the the the other artifact is the deployment script
31:56
Um this session is not about running database deployments but this is about
32:02
thinking about practice runs to Scott's great question of deployments to find
32:08
out what's going to happen before it has to happen Um database changes for an
32:15
urgent deployment are a much bigger pain than knowing we have this change coming
32:21
up and I can see in the script that there's something that we're going to need to plan for to be able to make this
32:28
change And so that's why if I look at my deployment script here
32:34
um you might remember from however many minutes ago that we had max length
32:40
columns and now we're reducing their size And if you if you think about um
32:47
what happens when you reduce the size of a column if those max length columns
32:54
went out to production I'm now needing to size them down And just giving a
32:59
quick perusal at this deployment script as kind of a you know squinting C
33:05
developer I can see already that hey we're altering things down into smaller
33:11
sizes That's that's going to be okay But that does mean that I need to check the
33:17
data that it's not going to get reduced in size There's no major red flags here
33:23
This is not a super long thing I don't see the database being the tables being copied into a temp table and then moved
33:29
over So this is a fairly small change but at least I'm able to give it a quick look now before I'm trying to ship out
33:38
those changes This deploy script is plain TSQL
33:43
code Um you could use this with different deployment paradigms Again
33:48
this is not about needing to adopt SQL projects This is about being able to pull in SQL into a development process
33:56
before you get to the point of doing deployments The other
34:06
opportunity when you're thinking about applying migrations is you don't want to
34:12
just have the application do database.mmigrate either someone is going to do the net ef database update
34:19
or you're going to do other SQL scripts However the good news is in addition to
34:25
deployment script there is also a deploy report function coming out of SQL package that'll give you similar XML to
34:33
that code analysis that you can parse as well to kind of do that practice run where
34:40
it's not changing the database but it's finding out what needs to happen and it's giving you output in an XML format
34:45
that you can then also have something parse through and read
34:51
So we've got our deploy script out of that and that was the other artifact And
34:57
then just in case you're wondering why did the first one fail and the second one passed it's not that the SQL project
35:06
build was failing but I was counting the number of errors um and warnings and
35:12
saying "Hey we can have one even two warnings but at the point that our code
35:18
analysis of our SQL gets to have three or more warnings this is the point at which we need to stop and pause." So you
35:24
can define the process for your environment if you have more mature databases where at the beginning you're
35:31
going to have 200 code analysis warnings like just very candidly like this this
35:37
is normal We we've built something it went out the door and now we're starting to introduce um database development
35:45
process to it That's okay You can even just never have the job fail but always provide feedback So you can set those
35:52
those uh parameters Now I have used up lots and lots of
35:58
great time today and I which I appreciate that you shared with me there's the artifacts So just kind of wrapping
36:05
things up and then to um answer Nikita's question in just a moment the the
36:10
toolbox basics that we needed to add to our EF core development getting database
36:18
development introduced in as a CI component was the SQL package CLI um
36:23
which I installed just like I would the EF um uh tool and then the SQL projects
36:29
templates I don't have to develop locally with a SQL project I brought one into VS Code just to kind of show off
36:37
but I don't need to do that to have a CI pipeline There's also a code analysis
36:43
template in this package if you want to start creating your um SQL project pack
36:49
Everything else around this development was net The toolbox itself is really rather
36:56
large when you start thinking about database development But these are tools that other people can use as a part of
37:02
that collaboration When you have that collaborative team setting where you have some people that are focusing on
37:08
different pieces of the application you have some people that are focusing on parts of the database but maybe they're
37:14
incorporating your changes And then there are additional groups of people that are potentially looking at using the data for analytics um you are going
37:23
to have points when there are schema changes that you need to um look at the
37:28
collisions on Um Visual Studio has a schema compare right now VS Code will have a schema compare um like
37:37
within a couple of weeks to a month You'll see that in public preview in VS Code in terms of merge conflicts in SQL
37:45
project files Um another awesome question because the Microsoft build.sql
37:50
SQL SDK that we saw in this SQL prod
37:56
file Um the large majority of merge conflicts
38:02
in SQL projects came in this project file itself where all of the individual files were listed Um the merge conflicts
38:11
were coming from that But moving to this project SDK that just went G in March um
38:17
you will not have merge conflicts in this file Now if you have conflicts in the object
38:24
definitions which would look similar to this then you do have to work through
38:30
those individually Um I do recommend using a schema compare um
38:37
visualizer which can write two projects because then you can see better which
38:43
instances might result in um data truncation or inadvertently losing like
38:50
an index that you don't want to lose So use those schema compare interfaces but
38:56
absolutely check out the SQL project SDK that'll reduce the number of u merge
39:03
conflicts So that is just an introductory primer to looking at
39:09
database development as a part of application development without having to necessarily change how you're
39:15
developing your database components Um those can still be a part of whatever application stack you're working on um
39:22
but then using that to enable you to see what you're building and shipping as a database component earlier Um so just
39:30
just don't forget the database Keep building and shipping Just don't forget the database Um if anyone has any questions
39:37
um additionally I'm happy to take them Uh those are some links for SQL package
39:44
um SQL projects if you want to automate anything around that and then the uh GitHub repo for the team that works on
39:51
SQL projects and code analysis and these things If you ever have any questions we're always happy to answer them there