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