We’ve started setting up our SQL in the City Summits for 2019 and the first one is London on April 30. I’m going to start making my plans now and hope to see some of you there.
We’re still finalizing agendas and getting some speakers lined up, but if you’re anywhere near London, take a day and come see us talk about DevOps, compliance, and Redgate.
At Redgate, we do a lot of research. Maybe not as much as Microsoft Research, but we are always trying to investigate more about customer problems and challenges before we build or change software.
Take our survey on SQL Server Configuration Management and you could win prizes. Or a prize.
I’ve never thought about managing an estate, but not that I live on a horse ranch, that has a little more meaning. In the past, I’ve managed hundreds of instances and thousands of databases. That’s certainly an estate, but even when I had 5 servers, that is something of a small estate of things to keep me busy.
At Redgate, we know there are lots of challenges in managing SQL Servers. We constantly have a team of people working on SQL Monitor, and they are releasing changes every week or two. In fact, we just released v9.0 this year, full of enhancements customers have asked for.
In addition to the tactical team that’s building and fixing things day to day, we are doing future research into where to take our monitoring and tuning software. That’s some of what this survey is about. Let us know about which things might help you smooth the process of managing systems.
Give us a few minutes and a little information and take our survey. You might find that a future version of SQL Monitor contains something you thought would be useful.
If you’ve had struggles with database development and had a real world disaster, you could win in a new Redgate contest. We’re looking for the places where old style, waterfall, traditional database development has been a problem. Especially when application software developers have been adopting DevOps, small, rapid release strategies.
Enter before Mar 20 and give us your story. Don’t worry, we’ll anonymize your name and company details. You can enter as many times as you like, but can only win once.
I started working with a small startup company that had 8-10 application developers. We tried to work in a rapid format, releasing a new version of our website every 2-3 weeks. This was going OK, but not great. Often we’d release and developers would go to test their new feature, only to realize that they’d forgotten a database component.
They would roll forward, finding code and deploying a database change during the release process, usually getting the feature working in 10 or 15 minutes.
Until they broke something else because they hadn’t really tested the database component complete. Or they realized they needed yet another database change. Or they had forgotten to code for some edge case that another developer tried during the release smoke test.
When I started, we all gathered in the office on a Sunday night and spent an hour or two releasing code. Not one of my favorite times.
The app developers were using source control, and trying to test, but they often sent code to QA and then fixed things in QA, forgetting that they needed to ensure those changes were deployed again to production.
Across a few months, we implemented what people would not call a DevOps process, reducing our release time to a few minutes, with myself and another developer on the phone, releasing automated changes from a CLI.
Database DevOps makes everyone happier.
Share your story before Mar 20 and good luck.
In my last post, I started out with a new SCA project, getting a connection to my database up and running. Now, let’s start the new project by adding some objects.
I’m going to start with a couple objects to make this simple, but we’ll move on from there in other posts to describe the options and details.
Our database is not terribly useful without tables, so let’s create a table. I’ll start by using a query window to build a table. Right click the database and choose New Query.
Once this opens, let’s write a query. I’m comfortable building tables like this, so I’ll add the first table to hold my SQL Server builds. I’ll write the code shown below and then execute this.
At this point, the development database has a change, but it’s not in my project. I need to use the SCA pane to let VS know that I’m ready to import this change. Open the pane and click refresh. The following should appear when the process completes.
In this dialog, we see a new table was found. The process compares the Shadow database, where no changes have occurred, with the development database, which has a new table. This gives me a “diff” in essence and I can add this to my project.
The change is checked on the left, so I can click the Import and Generate Script button. I’ll do that and I see the image below. There’s a lot here, so let’s discuss this after the image.
The first thing to look at is the script that’s active in the upper pane. If you notice, the tab name is on the right side of that upper left pane, highlighted in blue. This is my first migration script. You can see the migration ID at the top and then a PRINT statement, which is useful for logging during the build or deployment process, then the top of my code.
On the right side, in the Solution Explorer, we see that my script has been added to the Migrations folder. The default name has been applied, but I can rename this if I want.
In the SCA pane, we see a few things. First, the change is grayed out because the change was scripted. Above that, we have a yellow bar that notes a migration was generated, and it gives us the path in the project. Finally, there is a “Refresh” button to verify the script. We want to click that. This will use our script with the Shadow database to verity the code is correct. Once I click that, I get a note that the project was verified.
At this point, the Shadow and development databases are in sync.
This tells me that my changes should work when I deploy them to another system. Hopefully that works, and we’ll tackle that next time.
