I’ve been struggling recently with feelings of burnout. I’m sure many of you are as well. The world is a scary place right now, and it’s been tough to find purpose and meaning in a my job (which was often the refuge for a scary world).
I don’t have any real advice. I don’t really know what to do, but I’m not giving up hope. The only piece of advice that has ever worked for me is to talk about the issues, and try to get one thing accomplished each day. So today? I’m writing a short blog, which is something I haven’t done for a while. After that, I’m canceling most of my meetings, and going to write some code.
In a previous post, I described how to use an Azure Logic App to update an Azure DevOps work item; in an effort to add additional automation to our processes, I’m starting to move more and more notifications and work items directly to Azure DevOps using Logic apps. For example, for one of our websites, we have an SSRS report that queries the database to determine if employees are compliant with password policies. We get a weekly email that we then have to copy and paste into Azure DevOps (to track the work), and then we do the work. I want to eliminate the email step.
The workflow is very straightforward compared to updating an existing work item; there’s no need to manipulate a REST API for this. Connectors are all built in.
Set up a schedule using the Recurrence item.
Execute a stored procedure. This is the item that can be difficult to set up, especially if you have an on-premises SQL Server. In our case, I had to download and set up an on-premises data gateway, and then configure a connection to my SQL Server. Once that was done, I had to identify the database and stored procedure that contains the result set I wanted to add to the work item.
The result set from the stored procedure is in JSON format; parsing the JSON allows it to be defined as individual elements that can be referenced by additional actions.
I then take those elements and focus on the items of interest to construct an HTML table.
I then create an Azure DevOps work item by adding the HTML table to the description field.
BONUS: I added a timestamp to the work item title by using the formatDateTime() function.
A big part of my job these days is looking for opportunities to improve workflow. Automation of software is great, but identifying areas to speed up human processes can be incredibly beneficial to value delivery to customers. Here’s the situation I recently figured out how to do:
My SRE team uses a different Azure DevOps project than our development team. This protects the “separation of duties” concept that auditors love, while still letting us transfer items back and forth.
The two projects are in the same organization.
The two projects use different templates, with different required fields.
Our workflow process requires two phases of triage for bugs in the wild: a technical phase (provided by my team), and a business prioritization (provided by our Business Analyst).
Moving a card between projects is simple, but there were several manual changes that had to be made:
Assigning to a Business Analyst (BA)
Changing the status to Proposed from Active
Changing the Iteration and Area
Moving the card.
To automate this, I decided to use Azure Logic Apps. There are probably other ways to approach this problem (like Powershell), but one of the benefits of the Logic Apps model is that it uses the same security settings as our Azure DevOps installation. It just simplifies some of the steps I must go through. The simplest solution I could implement was to move the work item when changing the Assigned To field to a Business Analyst. This allows us to work the card, add comments, notes, but when the time comes to hand over to our development team for prioritization, it’s a simple change to a key attribute and save.
Here’s the Logic Apps workflow overview:
The initial trigger is a timer; every 3 minutes, the app runs and looks for work items that exist in a custom AzureDevOps query. This functionality is built into the Logic Apps designer as an Action for the Azure DevOps connector. The query exists in our SRE project, and simply identifies WorkItems that have been assigned to our Business Analyst Group. Note that the BA group is a team in the SRE project.
SELECT
[System.Id]
FROM workitems
WHERE
[System.TeamProject] = @project
AND [System.WorkItemType] <> ''
AND [System.State] <> ''
AND [System.AssignedTo] IN GROUP '[SRE]\BA <id:56e7c8c7-b8ef-4db9-ad9c-055227a30a26>'
Once this query returns a list of work items to the LogicApp, I then use a For Each step in the designer, and embed a Rest API action.
The Rest API action offers maximum flexibility to update values for a work item; there is also an Update action, but the options were limited. There was once gotcha; you have to add the content-type, or it throws an error: application/json-patch+json
The code is below; it’s JSON, and the syntax is that you specify an operation (“add” for both updates and creates), a path to the field you want to change (path), and the value you want to set it to. In this case, I’m changing the Project, The Area Path, the Iteration Path, the State of the Work Item, and adding a comment to the Symptom field.
I used to love the Windows version of LiveWriter, and saw a tweet today to let me know that an open-sourced fork of it was available. This may restore my love of blogging; the interface is simple to use, and doesn’t feel as unfamiliar as the “blocks” used in WordPress these days.
The tool is a bit rough in places; I couldn’t get plugins to work, and pasting the above image from the clipboard also was challenging, but overall, it’s a welcome advance. Just feels natural to an old-school blogger like myself.
One of my tasks over the last few years is to keep management and senior management aware of software deployments for our hosted services. This started out as a CAB (Change Advisory Board), but all of our deployments quickly became standard, and it basically became a monthly review of what had happened (which is not what a CAB meeting is supposed to be). I figured a meeting wasn’t necessary, so I was looking for a way to show what we’ve done in an easy to digest method.
Below is the flow that I came up with. At first it seemed relatively straightforward to pull together, but the stumbling block was the fact that the HTML tables are VERY rudimentary. No styling, no hyperlinks, nothing. That’s the reason for the additional variable steps.
The initialize variable state is where I define a string variable to handle the output of the Create HTML Table step. It’s empty, until I set it later (in the Set Variable) step. The Create HTML table was mostly easy, except that I wanted a defined border, and a hyperlink that would allow recipients to click on the link and get to the specific work item.
The set variable then takes the output of the Create HTML table step, and replaces the placeholders with appropriate HTML tags. In this case, I added a table border, and made a hyperlink out of the ID column.
Lots of good ideas, but can’t seem to find the time to actually sit down and write about them. At the end of the year (2020), I had a major health scare; turned out to be ok, but it was significant enough to wake me up. I’d like to write about that someday.
I’d also like to describe my network setup. I’ve spent a lot of time working from home, and trying different approaches to staying connected. I’ve finally landed on a solution I like, and I need to spend some time diagramming it.
I should also blog about my job, and some of the challenges and fun stuff we do. I’ve recently started card games at lunch with my team, and I’m hoping that’s going to spur some new relationships. I’ve also started using a PIP tracking tool to help guide conversations with an employee who needs specific guidance (which is a weakness of mine).
So here’s the deal; consider this a blog post about blogging. My goal is to write one of these by the end of the week.
And you’re probably going to see a ton of retrospective posts going live soon from a variety of authors. I’m struggling to write… well, anything…. That being said, I’ve had a few key successes over the last year.
Job is good; learning lots of new stuff with Powershell and OCtopus Deploy, as well as Azure DevOps.
We got an awesome dog. Meet Conway.
Of course, lots of other stuff happened too. COVID decimated travel plans, and as most of you are aware, it killed an organization that I’ve been a long-time member of (PASS). It also cancelled the SQLSaturday Atlanta for 2020, perhaps indefinitely.
Top it off with some health stuff, and frankly, I’m exhausted. However, I do have this urge to make the most out of the next year, and the only way I know how to do that, is to get back in the habit of writing.
I usually try to write these Three Things I’ve Learned posts at the end of each day of a conference, but this is a little different. This is the first multi-day virtual training event I’ve been to, and because it’s virtual, there’s no travel. Which means my day begins on EDT, and the conference starts (and ends) on PDT. Makes for a very long day.
That being said, I love this conference: DevOps Enterprise Summit 2020 continues to push me to think abstractly about technological problems, and grounds me again in looking at cultural issues within my organization. These are the three things that have resonated with me (so far):
I’ve got to do more to make the pain visible across the organization. Lots of folks have stressed the necessity of communication across teams, disciplines, and to the upper management, and that’s really sticking out to me. I think we’ve done a decent job of complaining, but we haven’t done the best job of proposing better ways of solving problems.
I need to celebrate my team’s victories more. My team works hard, and there are moments when they feel forgotten in the grand scheme of things, particularly when other teams are holding them back. I need to make sure that they realize how much change they’ve promoted, and how far we’ve come as an organization.
Set the Vision, but focus on the first step. A few years ago when I started us on this journey, I laid out a vision, and I need to revisit that. A lot has changed, including both targets we hit, and goals that are no longer on the roadmap. I need to make sure that I frame each step along the way in terms of the value it brings to the service we’re offering.
Virtual conferences are a different kind of fatigue; it’s been rough staying focused. I think I’m going to write another blog post to describe what’s worked for me, and what I’ll do differently in the future.
This is one of my favorite conferences, and obviously COVID-19 changes everything. It’ll be interesting to see how going online changes the tone of the conversation. One big benefit is that the cost is definitely lower while the quality of the content is expected to be the same; I miss traveling, though.
I know most folks have done a virtual conference this year and have already mastered the Zoom burnout, but I’m a little concerned about. I’m going to try and beat it by staying engaged with a co-worker who is also attended. I also plan on live-tweeting and or blogging as it comes.
Haven’t blogged in a bit, and I definitely need to get back to writing. However, just wanted to post a quick note that I’m super excited to be presenting a guest session with RedGate Software‘s Grant Fritchey at the DevOps Enterprise Summit. I’m very excited about this for multiple reasons:
I love this conference; DOES is very inspirational, and there are lots of great speakers and content. It’s focused more on the technical goals than the actual tools, so it’s a good fit for where i am career wise.
I love RedGate Software. Their company is simply an amazing producer of tools for the database community, and they’ve been very supportive of #sqlfamily and #sqlSaturdays for a long time. I’m stoked that they’re expanding their reach.
Grant‘s ok. (Really, he’s a great guy and a lot of fun to talk to).
See y’all in virtual Vegas. Registration for the conference is half-price through August 31; it’s a great deal at $325.