Voice of the DBA

Tag: DevOps

Delete an Azure DevOps Project

Not something you’ll do too often, but you might find yourself doing this if you are setting up PoCs and removing them. A reminder for me, since I stumbled around for 5 minutes before Googling and finding a note on the docs site.

Project Settings

This is the key, and there are a lot of useful things here, including deleting your project. To get to the settings, open your project from Azure DevOps. In the current view, you see a number of items along the left: the overview, repos, pipelines, etc..

Look below these items and you’ll see the gear icon. That will take you to the settings.

The settings page as the name of the project, and a number of tabs on the left. You can change lots of the items, but for this post, stick with the Overview.

Below the Process, are the various sections of Azure DevOps listed, the Boards, repos, etc. If you scroll down the Overview page, you’ll see the Delete Project at the bottom.

Click this, and you’ll get a confirmation dialog. You need to enter the correct name of the project to delete it.

Microsoft knows this is a big deal, so you have time to recover this if you make a mistake. That doesn’t mean you shouldn’t treat this seriously, but in case you make a mistake, you can recover things right away if you need to do so.

Once you start to experiment and work with Azure DevOps, you can find the number of projects will grow. Some of those will be test projects or PoCs, which need cleaning up at some point. This is the process to remove those old projects.

September 16, 2019
The State of DevOps Report for 2019

It seems like just a few weeks ago that I went over the 2018 results with Gene Kim. That was an exciting few weeks for me, running over the report in prep and then having the opportunity to host a webinar with Gene Kim. Exciting times, but it’s been almost a year and the 2019 report is out. You can download the 2019 Accelerate: State of DevOps Report from the DORA site and read it yourself, but I found a couple interesting things in the report.

As expected, companies adopting DevOps are outperforming those that don’t, at least in the metrics measured. In fact, it appears that the high performers continue to outperform low performers in two major ways: speed and stability. What’s interesting, and as was pointed out by Kendra, is that these aren’t on the same scale, meaning there isn’t a trade-off between the two metrics.

You can move fast and achieve higher stability. In fact, moving fast can lead to higher stability if you are learning and growing from your efforts to build and deploy software. This includes the database, though that’s not called out in this year’s report. Instead, the report talks about ways to achieve speed and stability.

One of those is tools, and more importantly, easy to use tools. Staff will turnover or change positions. Knowledge can be hard to share in busy environments, so tooling is important. Bespoke, bought, homegrown, open-source, it’s important that the tooling is easy to understand and that it performs at some job in an efficient manner.

There are other items in the report, but one thing I think we often ignore is that sticking with your old process and people doesn’t mean you’ll fail. You clearly have some people and process in place that works, as you’re in business now.

However.

Both speed and stability help you work more efficiently. They help you compete better against others, and should ensure you reach your goals sooner. Speed increases value for customers, which in turn should help you improve how your organization functions. Stability makes both customers and staff happy. One thing the report points out: productivity has a positive impact on workers. They deal with stress better and burnout less.

Happier employees are hopefully helping your organization with more creativity in solving problems, more engagement with customers’ success, and less turnover. DevOps is better for your software, and your staff.

If you want to learn more, I’m hosting a webinar next week with Jez Humble to go over the report.

Steve Jones

Listen to the podcast at Libsyn, Stitcher or iTunes.

September 12, 2019
Finding the Visual Designer in Azure DevOps Builds

This post is really a reminder to me, since I don’t create pipelines all that often, and I’ve forgotten a few times how to do this.

Plus, while YAML is nice when you want to scale things, it absolutely sucks for getting started. It’s a horrible default and, IMHO, is the worst decision of the Azure DevOps team since the VS 2010 Release Management days.

When you create a new project, and then select Builds in Azure DevOps, you’ll see something like this. It might be slightly different as the product continues to evolve every few months.

This looks inviting, a pipeline should be easy. When you click New Pipeline, you’ll get a choice. The intention here is that Azure DevOps wants to help you get started.

Don’t be fooled. If you say your code is in GitHub, you’ll get a YAML pipeline and you can’t convert back? Why? Apparently the developers at Azure DevOps don’t want to write GUI interfaces that render YAML code.

Instead, at the bottom of this section, there’s a “use the classic editor” link. Click that.

Once you do that, you still have all the choices for code repos, and it’s easier to get your build started.

Hopefully I’ll remember that next time instead of fumbling around.

September 9, 2019
Demo Data for Everyone

As someone learning about DevOps, I follow a number of people, one of whom is Gene Kim. When I see him get excited about a post, I usually read it. That’s how I found this post on Demo Data as Code. It’s a short, but interesting read. I think this is actually something more people ought to implement in their environments and not just for demos.

DevOps is about reliability and repeatability, among other things, but those two are tackled with automation for a known process. We don’t want simple, silly mistakes, or even complex errors that might undermine our ability to move forward and create value. We don’t want simple errors eating up resources and time from expensive talent with unnecessary work. Part of ensuring both repeatability and reliability involves using data in our databases to evaluate our application. This isn’t necessarily for demos, though it could be used for demos.

Once of the areas that is often left out of the process is the data that we use in our building our systems. We need some data for developers, for QA, and often for demos. In all of those cases, when humans need to repeatedly look at how well the software performs, and want to re-test things, they need some consistent data. I’d also argue that the need for agility means that we need a manageable data set. I think SQL Provision from Redgate is amazing, but I still don’t want to always develop with 2TB of masked data. I certainly don’t want to demo this for customers from a laptop, and might not want to share this in the cloud.

At Redgate, we sell masking with SQL Provision, and it supports most of the process that’s outlined in the Demo Data as Code article. What it needs, however, is a small set of data that can be masked in a deterministic fashion. What I recommend to most clients is that they build a known set of test data, which could be used for demos. This can include all your edge cases and show off new features. It’s helpful for developers, testers, and salespeople, who will always have a known, useful set of data.

This can’t be a build it and forget it, much like what is emphasized in the article. This will need to be altered over time. There ought to be a process to build this dataset, likely from production data that gets sanitized. This can then be distributed through SQL Provision (or similar technology), with backups, or even as a set of scripts in your VCS. Ensure an environment can be hydrated instantly on any platform, from a developer workstation to a sales laptop to a QA server. Once you have this, everyone can work on evaluating your software from a known baseline.

And if you find the need for more data, then just add it. You have a process, so add an additional step that will cover the holes you inevitably find.

Steve Jones

Listen to the podcast at Libsyn, Stitcher or iTunes.

August 14, 2019