, 0 comments , , , ,

Eight Minutes to DevOps Joy: Easy Azure DevOps Pipelines

Quick hit: I’m trying to help developers get up to speed with the basics of modern devops. A lot of online courses and video tutorials are really long and go into more detail than is needed for a new person to get started. I don’t believe in delayed gratification! Thus… “Eight Minutes to Devops Joy!”

The idea is to reveal the “Happy Path” quickly, so people can do useful things right away. Additionally I’m giving suggestions for where they might need to make decisions or do further research.

Here are the first two videos in the series: One to create a build pipeline in Azure DevOps, and one to create a release pipeline in Azure DevOps. Share and enjoy!

An Easy Azure Build Pipeline

Get started using Azure DevOps to build an existing Angular application. In eight minutes, you’ll see how to import a Git repository, create a pipeline, set up task details, and kick off a build under “continuous integration.” The video is fast, and it only covers the “Happy Path”—a simple case without too many complicating details and no troubleshooting. If you want the quickest possible introduction to the subject, this is it.

An Easy Azure Release Pipeline

Pick up where the prior video left off. Use Azure DevOps to create a release of the Angular application you just built. In eight minutes, you’ll see how to set up storage, set up a static website, configure public read-only access, tweak the build pipeline definition, create a fresh release pipeline, set up a single Azure CLI task, and kick off a release under “continuous deployment.” This video is fast too, and it only covers the “Happy Path”—a simple case without too many complicating details and no troubleshooting. If you want the quickest possible introduction to the subject, this is it.

, 0 comments , , , , ,

How change breaks: four patterns to know about

I’ve been studying corporate enterprise systems for thirty years and have worked with about eighty different organizations in the process. Most of them had mission-critical applications that failed a lot. I was the software “jack of all trades” who came along to remedy those failures.

Out of that experience, some incredibly strong patterns have emerged, which have illuminated my problem solving this whole time. These patterns are themselves consistent, reliable, and solid—even though the phenomena they describe are complex, expensive, and often painful to deal with.

Pattern: Change is the enemy

Spoiler: alertness is key. (Photo by @Mawi on Twenty20.com)

First off, if a working system stops working, it’s because something has changed. That’s obvious, right? If your enterprise system is working, and if you’re able to keep everything around it from changing, you will have perfect reliability—so any failure must be a result of some kind of change.

That includes code, configuration, operating systems, APIs, and database schemas. But it also might include availability, which could change suddenly and without warning. And what about changes that are entirely unauthorized, such as malicious changes that should have been spotted by your intrusion detection system?

So we start with an incredibly basic principle: If you want a guarantee of zero risk, it means you have to have zero change.

More

0 comments , , ,

Tech fail: deploying to blobs

Maybe this is a rough draft. I wanted to write this all down before I forgot. Long story short, these things don’t go as well together as you might expect:

  • Azure blob storage
  • A “static” website that relies on Javascript
  • Azure DevOps Release Pipelines

I burned a couple of days on this foolishness. Given that cloud tools are always changing, it’s worth noting that I did it in the last couple days of June 2020 and your results will vary.

Original plan

I have an Angular 9 application that builds nicely in a Build Pipeline. That went rather well, so I had useful Build Artifacts in my output. The idea was to use a Release Pipeline to shove my dist folder into Azure Blob Storage using the “$web” container convention.

Therefore, my Release Pipeline should be just an Azure File Copy task, right? Wrong.

After a tremendous amount of fussing around, I discovered that when I completed a Release I could access index.html through my web browser (and curl and whatever other means) but it was looking blank because it couldn’t load any of the bundled Javascript files. And it couldn’t load the bundled Javascript files because the Content-Type of the blobs they were stored in was set to “application/plain”.

I googled around a lot, and found helpful advice to add a switch like /ApplicationType to the Azure File Copy task, but that was for a long-past version of the Task. (Maybe I could have used it anyway. IDK.) I also found some advice to set up a file called AzCopyConfig.json that the azcopy.exe executable would automatically interpret to map file extensions to Content-types, but [shrug emoji] after jumping through some hoops that didn’t seem to work either.

What did work finally was writing a little PowerShell script that did something like this:

$container.CloudBlobContainer.Uri.AbsoluteUri
    if ($container) {
        $filesToUpload = Get-ChildItem $sourceFileRootDirectory -Recurse -File

        foreach ($x in $filesToUpload) {
            $targetPath = ($x.fullname.Substring($sourceFileRootDirectory.Length + 1)).Replace("\", "/")
            $extn = $x.extension
            $contentType = ''
            switch ($extn) {
              ".json" { $contentType = "application/json" }
              ".js" { $contentType = "application/javascript" }
              ".svg" { $contentType = "image/svg+xml" }
              ".html" { $contentType = "text/html" }
              ".htm" { $contentType = "text/html" }
              ".png" { $contentType = "image/png" }
              ".css" { $contentType = "style/css" }
              ".ico" { $contentType = "image/x-icon" } # or "image/vnd.microsoft.icon"
              ".txt" { $contentType = "text/plain"}
             Default { $contentType = "" }
            }

            #Write-Verbose "Uploading $("\" + $x.fullname.Substring($sourceFileRootDirectory.Length + 1)) to $($container.CloudBlobContainer.Uri.AbsoluteUri + "/" + $targetPath)"
            Write-Verbose "Uploading $($x.fullname) to $($container.CloudBlobContainer.Uri.AbsoluteUri + "/" + $targetPath) as $($contentType)"
            Set-AzStorageBlobContent -File $x.fullname -Container $container.Name -Blob $targetPath -Context $ctx -Force:$Force -Properties @{"ContentType" = $contentType} | Out-Null
        }
    }

, , 0 comments , , , ,

Checklist of suck: Wrong Tech Approach

Everyone wants their software development projects to go well. Nobody wants their project to suck. And yet, the world is full of Software Development Projects That Suck! Why is that?

I’ve worked with about eighty different companies on their software development projects over the last thirty years or so. They’re all different, but not so different that some patterns don’t become apparent. So let’s talk about a few things that go wrong super commonly.

People don’t like long blog posts, so for right now here’s just one.

Persisting with a technical approach that doesn’t work.

Wow, this one is hard. You’re trying a new technology stack and engaging a big new project at the same time, and it’s harder than it looks. Maybe you find that a critical component is in pre-beta, or incompatible with your architecture, or totally missing.

You can prevent this by learning with small projects that carry low risk before you commit to the platform shift. If management insists on implementing a larger and riskier project before your team is really good at using the new platform, you need to push back. (Sometimes there is no substitute for courage and politics.)

If you find yourself in this particular kind of Suck already, you have two decent options.

One way is to get out of the new stack quickly. Start over. It hurts but it hurts less than going two years and having nothing really working. The obvious problem here is that if you weren’t able to persuade management not to put you in this particular jackpot in the first place, you probably won’t be able to persuade them to let you start over. (Once again, tech can’t solve your management problems.)

The other way is to get help. One time I saw a big web design company take on a non-trivial Sitecore project even though they didn’t have any Sitecore chops. That was going badly until they brought in a partner company that focuses hard on Sitecore development! I’m pretty sure the first company lost money on the project in the end, but it did get done and they avoided the bigger Suck of walking away from a multi-million-dollar fail.

Sometimes it’s you.

A lot of times it’s not the “stack” though, it’s you.

A pattern I see now and then is when developers get a little too ambitious, un-Agile, and try to solve some bigger problem than the project at hand. For example, I was on a team once that was developing a really small web application, not much more than a “Contact Us!” form, and it took four of us about six months.

Six. Months.

Because the lead person had a great architecture concept which we ended up calling “The Framework.” I don’t recall the details, but I think the gist of it was that he was implementing a data-driven content management system rather than straight up regular ASP.NET pages. Sort of like using WordPress for a site that didn’t need that much of a feature set… except he was busy actually inventing WordPress at the same time.

A long time ago I got stymied on a solo project when I attempted something a little similar. It was a reasonably normal parent-child-grandchild data entry application with a few neat user interface features. The platform (mid-1990s, CA-Visual Objects!) didn’t have a great standardized CRUD paradigm built in, so I tried to write one that was hyper-generalized and sort of clever about normalization.

Over a data store that was still ISAM tables. Yikes. It worked in theory!

What I’m getting at here is the Agile concept of doing today’s work today. Today you are implementing a Contact Us page. Today you are implementing a CRM front end. Today you are implementing a configuration monitor. You are not replacing WordPress! You are not creating a Framework for all future development!

Long story short, if the vendor platform was a bad choice, you need to get help with the platform or get out of the platform. If the internal architecture was a bad choice, you can set aside the “big ideas” and refocus on the original project as defined and let go of the architecture mistake.

What have you tried?

Comment and share! Have you had a Project That Sucks because you were using a tech stack that didn’t suit your team or purpose? Or because your own architecture was beating you up? What did you do? Did it help or are you still sad?

And there’s help!

If your project sucks, let’s talk about how to make it not suck! Starting with the Checklist Of Suck process!

, 0 comments , , ,

The trouble with Scrum

For about the last ten years, most of the development shops I’ve seen and worked with are operating under a process that is Scrum-like on the surface. It’s standard to divide work into “stories,” to assign points to those stories, to organize time into “sprints” that are just about always two weeks, and to move those “stories” from left to right on a Jira board.

I have many, many things to say about how people mess up Scrum. A lot of it is embedded in the prior paragraph: they’re “Scrum-like” on the surface but they don’t even try to embrace the values of “commitment, courage, focus, openness and respect” that the Scrum Guide calls for.

More

Unclear on the concept

, , , 0 comments , , , ,

Unclear on the concept

Management people are funny. They want “agile” development, then they get mad when you focus on early and continuous delivery of valuable software.

At the risk of sounding grumpy here, if you have some competing agenda then your “agile” efforts will fail.

Who doesn’t want early and continuous delivery of valuable software?

Sounds like a trick question, right?

It’s not. Here are some competing agendas I’ve seen up close:

More

0 comments

First rule of public speaking

I’ve been away from the “tech scene” for a little while. Other priorities got in the way of hanging out with other software people in any organized or ongoing way. And last week was a little sad, as all my regulars were out at CodeMash without me!

Very recently though I was prompted to check out a tech meetup. I showed up fifteen minutes early, but the program was advertised as being a half hour late, so it netted out to missing the first little bit. Maybe I missed something important.

The topic was a type of business modeling that works on many levels, which is great, but unfortunately the speaker brought his boardroom pitch and boardroom slides. So we, a roomful of implementors, were treated to an hour’s worth of what could have been titled “Why you, a CEO, should adopt this high-level management technique.”

It was a lot of drill-down. It would have been good if we had money and were thinking of hiring his firm to consult with us.

The most important rule of public speaking, which probably isn’t written anywhere but should definitely go first, is “Read the room.” The speech you give in a meetup of implementors is not the case you make to your boss in your annual review is not the testimony you give as an expert witness is not the war story you tell over drinks afterwards even if you’re conveying the same concepts.

A much better presentation would have been perhaps to start with a story, or two really brief stories, illustrating the management practice at a tactical project level. Show how it creates a win. Get people to notice that the thing you’re talking about is actually relevant to their daily lives. Then summarize the management principle you came to talk about and introduce a nice catchphrase that gives people a hook so you can easily shout it out later. Give a brief example of how your C-level people might apply the principle even though it’s likely to be above our pay grade. Then circle back and talk about how we might benefit from applying this principle directly, maybe using two or three clear steps that help us confirm that we’re on the right track.

Everything has to start with “So what?” and “Why are you saying this to me?” If you don’t establish those two things you don’t have an audience, you have a bunch of people who probably feel somewhat socially obligated not to walk out of the room.

More importantly though, I think you have an obligation. People have sacrificed time and energy to come hear what you have to say, and it’s your job to provide enough value to make that sacrifice beneficial. You’re obligated to make the time interesting, relevant, and useful.

And in the context of a gathering of tech implementation experts, that means not recycling your CEO pitch.

, , 0 comments , , ,

An analogy that might help

We just got hired as a jazz band, which is great. But there’s this one guy who insists on playing drums and only plays marching music. It’s the way he’s always played music and it’s all he knows. He is absolutely willing to play in the jazz band but will only play a marching beat. That’s okay, right?

I had a long talk with a new team last week. They’re doing a hybrid agile/waterfall approach on a project that needs tons of changes to reach viable status. My old pal Paul got in touch to ask me about some “intricate” issues.

More

Page 1 of 12
1 2 3 … 12
1 2 3 4 5 ›»