Month: July 2019

PartsUnlimited hassles with grunt-sass …

I’m putting together some notes for an upcoming presentation on LaunchDarkly and feature flags, which I love… This is some notes around some issues I had with setting up the sample PartsUnlimited project. You’d think this would be a slam-dunk; as with all things Visual Studio, it’s not always a direct route that gets you there.

First off, I first tried standing up a dev environment in Azure (slam dunk, and got a souped-up box for $0.11 an hour – whoa!) – and pulling down the demo content. This all worked great, until I tried to build the solution in Visual Studio 2019. I get this error message though that there’s a broken dependency – “local Npm module grunt-sass not found”. Hmm.

After having repeated issues with it, I gave up and walked through these steps start to finish, explicitly – including installing VS2017 Enterprise in parallel with 2019. That means you install an older version of .NET Core (2.2.108), NodeJs (v6.12.3). Guess what? Still had the same issue around grunt-sass. So, looking back, I think I could get it to run on VS2019 no problem – I just had to clean up the project dependencies using “git clean-fdx” cmd-line at the project level, or – last resort – npm uninstall node-sass, followed by install.

Anyway, just to wrap up – for a starter project it’s a little disappointing you have to jump through a fair # of hoops to get it to work. The references are badly out of date and you’d think it wouldn’t take much work to keep it up to date with current versions. But, the fix was fairly easy – navigate to the solution folder (root) and running “git clean-fdx”. If that had failed, I could have uninstalled and then installed node-sass packages (npm uninstall node-sass, then npm install node-sass)

Some thoughts:

  • So much good stuff there on the Azure DevOps Demo Generator site. Once I’m done w/mucking around with Terraform, I’m coming back to explore?
  • Is it annoying that they completely changed / lobotomized the MSDN subscriber downloads site? You bet it is.

 Anyway, the project builds, no errors. Really a very minor hiccup and in a bizarre way I kinda had fun knocking down potential issues until we hit on the right path.

New Podcast – interview with Nathen Harvey of Google

Great interview with Nathen Harvey – I sat down with him again after a year or so, back when he was at Chef. I love that guy and he’ll continue to rise in our industry! I knew I’d found a goldmine the first time I talked with Nathen, way back a year ago… He has so much practical experience around configuration management – he was a longtime employee at Chef and rocked a lot of great presentations. A very engaging and stimulating guy – you’ll love it. I think you’ll love this discussion, which explores some of the topics we covered in his interview in Achieving DevOps!

A link to the interview is here – and it’s on the podcast platform of your choice. Apple, Google, Spotify, blah blah…. Click below to check out the podcast. We’re on all the major platforms now, including AnchorAppleGoogleSpotifyPocketCasts, and RadioPublic.

Here’s some of the topics we covered:

  • So there’s a few Git flavors out there when it comes to branching – gitFlow, Github-flow, Gitlab-flow, etc. What do you favor? (And how long lived can a feature branch be anyway before it becomes an antipattern?)
  • How do you build up empathy between different roles – i.e. engineering and Operations/IT?
  • In the dawning era of containers and provisioning tools like Terraform – do we really still need configuration management tools like Chef, Ansible, etc?
  • Let’s say we want to start up a DevOps Dojo – a POC. Where do we start? (i.e. why is a Hello World project not enough to get traction…)
  • How do we get executive buy-in?
  • What’s resilience engineering, and why is that important?

Enjoy the podcast!

 
 

 References and Links

 

 

A Cloud Migration That’s Going Somewhere – the Humana Story with Jon Cwiak

About a year ago I had the pleasure of meeting with Jon Cwiak, an enterprise architect at the insurance giant Humana. I love the Humana story and I’ve been watching them overcome obstacles and challenges along the way – they always move upwards and their cloud migration effort is really starting to gain traction.

Jon’s one of those hero architects I wish were more common in our industry; he’s a purist with a very strong vision of what cloud development and architecture means, but he’s pragmatic and engaging in how teams chart their course to get there. I think you’ll love this discussion, which explores some of the topics we covered in his interview in Achieving DevOps!

A link to the interview is here – and it’s on the podcast platform of your choice. Apple, Google, Spotify, blah blah….

Here’s some of the topics we cover in the podcast:

  • Humana’s swing for the fences with their cloud migration
  • Why do good architects start with empathy – and what impact can this have on a project?
  • “DevOps isn’t a role or a title – it’s a set of practices that you do.”
  • How does Humana build a sense of community, and what 4 pillars do they look at in migrating workflows to the cloud?
  • Does Humana insist on a specific set of tools for monitoring, release, etc?
  • What does monitoring look like at Humana? And what about security – how does Humana handle their data stewardship without overloading engineers?
  • Does everything need to be a microservice? Where does Humana start in peeling off services and flows that would be a good fit for microservices?
  • On COTS products and buy vs build – “You buy for commodity and build for differentiation. I’m not going to build my own log analytics platform – that’s a solved problem. Then I can go on and solve more interesting problems.”
  • Moving away from big, destructive tsunami releases: “Shipping is a feature – do so early and often.”

 

I really enjoyed my talk with Jon, and I think you will too! Let me know what you think, and enjoy!

DevOps Is About Habits, Not Outcomes

It’s a Friday; a good time to reflect and think a little about what I’m grateful for, and what I’ve learned. I wanted to share with you a little story and what it taught me about myself and how to create lasting change.

In November of 2018 I went in for a routine checkup to my doctor. It had been a while – like five years – since my last visit. A few days later I got the news: I had full-blown Type 2 Diabetes. I go into this more in my book, but this was shocking to me, and I went through all the stages of denial, anger, and guilt. Guilt especially – diabetes is a lifestyle disease. I had done this to myself, with too much pizza and beer, too much time on the couch.

While I was struggling with coming to grips with my new limitations, I found two amazing resources: “Tiny Habits” by Dr BJ Fogg, and the book “The Power of Habit” by Charles Duhigg. Both are game changers. Finally, I realized why all the grand resolutions and big pushes I’d made to change my lifestyle had ended up in failure, and how to create change that sticks.

Basically, I was trying for a “Big J” – an all out effort, based on a big New Years Day type resolution. “I am going to lose 30 lbs in 3 months!” To do this, I’d embark on all-out ‘personal transformations’ – radical diets, 2-hour gym torture exercises. You know the deal! Well, guess what – maybe a few weeks later, or a month at most, I’d be back on the couch – discouraged, depressed. What had happened?

Interestingly, a friend of mine had a similar “now what?” moment – when a doctor told him he needed to change or he’d be dead in ten years. My friend went home and decided to try something he liked – getting on a bike. So every day when he got home, he’d bike 3 miles from his home. This was an easy, low-effort habit to start with. After a month or so, he started going for 5 miles… then as far as 10, on weekends. Then he joined a riding group. Three years later, he’s dropped thirty pounds – all by doing something he likes, starting small, and gradually ramping up his positive habit.

Too much change, too fast, is a sure recipe for failure. It takes a significant amount of energy to get up and go to the gym for 2 hours, for example. I’ll bet, after a week or so, you’ll hit snooze on your alarm clock and go back to bed – or a friend will come to visit – and that speed bump will leave you right back where you started, frustrated and discouraged.

Both Charles Duhigg and Dr Fogg point out that like any other chemical reaction, it requires energy to start anything new and overcome inertia – something called “activation energy”. Lowering that activation energy is the key for success. So, you might do something simple – like lay out your clothes the night before, so its easy to get to the gym. Or you could start with a 10 minute a day goal in the gym. The point is patience. It took you years to get to this point; it’ll take you years to dig your way out.

I’ll repeat those three common factors in failing to create change:

  • Trying too much change too fast.
  • Not planning for failure. (Something is going to break your routine. What then?)
  • Thinking in terms of big outcomes and aggressive goals.

But the point is, what you are trying to do is not based on an outcome. You aren’t thinking about losing 30 lbs for example. You’re trying to establish a habit, one that sticks. Dr Fogg for example started with doing a single pushup every time he went to the bathroom. Five or 10 pushups would have been too much – a single pushup was just right for that low activation energy target. And a year later – lo and behold, he’s doing 50 pushups a day, easily and without much effort.

So to create lasting change, we want to change that big “J” shape to a bunch of little J’s. Something like this:


Change means risk, and risk means… well, you know. A lot of companies attempt the “big push” like this – calling it a “DevOps transformation”, or a Digital Transformation, or a Cloud Migration. Most will end up in failure, and the reason why is simple: too much change is happening too fast, and often their measures of success are targeting outcomes. They’re not thinking about habits, and they’re not taking into account the constraints of the enterprise. Put simply, change means risk – and most enterprises have a long successful history of operating in a certain way. A company like that simply does not pivot on a dime.

That’s why you’ll see many of the people presenting at DevOps events working elsewhere a few years later. Change is risky. If we fail in financial goals, we end up in debt to credit cards, discouraged. If we fail in health goals, end up on the couch, frustrated, apathetic, risk health. And if we fail in managing change for our company, make promises we can’t deliver on, that’s a career ending decision.

Here I have to give a shout out to my favorite local gym, 3 Peaks Crossfit. About 8 months ago, I started going, and I hated every day. Some weeks I could only go a few times – but I told myself I’d give it a year to see if I could make this one habit stick. They do a few interesting things:

  1. They are all about building habits. So it’s encouraged to sign up for classes, so you’re accountable – and to come in as often as possible. Daily is best.
  2. They have a whiteboard on the wall, where you write down what you lifted, or your time. It changes every day, but over time you can clearly see progress.
  3. The workouts can be tuned so that anyone at any fitness level can participate. Some people do full-on pullups – others stay on the ground and swing their legs. But, everyone is moving, and no one is stretched too much beyond their limits.

 


Think about how to make your goals small and achievable. Remember the three keys for success with lasting change:

  • Small and achievable
  • Simple and clear
  • Habit oriented, not about outcomes.

What does that look like in DevOps? It could look something like the following:


I just pulled out a few sample limiting factors, and what might help address that pain point. But making this even simpler – if we treat the delivery pipeline like a garden hose, the problem COULD BE in the middle somewhere. Say it’s not using version control for our environments (DevOps has been defined as ‘coding for Operations’), or infrastructure as code. Or maybe it’s a worthless or missing test layer, so our deployments constantly fail. But quite often we find it’s the beginning or the end of the hose that’s the problem. Maybe we’re making guesses on what features will be valuable, so 75% of our development is being wasted. (Imagine being able to multiply your dev staff by 4x! That’s what HDD can offer.) Or we have no blameless postmortem process, so bugs keep getting swept under the rug and problems keep getting repeated. Or there’s no telemetry or monitoring to knock down problems quickly and keep our availability up.

Enough with the nerd stuff though. Getting back to that gym, and what makes it special – they’ve got a list of values on the wall. It calls out specifically that negative talk, about ourselves or others, is not allowed. Crossfit recognizes that out of our thoughts come our abilities. So let’s be careful about labels. If we think and say things like:

  • “I’m stuck in a rut.”
  • “I never get ahead.”
  • “I’m lazy.”
  • “I’m incompetent.”
  • “My boss hates me.”
  • “I can’t because…”

We are creating a negative feedback loop, reinforced by the language and labels we give ourselves. But if we say:

  • “I love learning.”
  • “I’m capable of anything.”
  • “I always do my best.”
  • “I’m a great teammate.”
  • “In this one area I can…”

Whoa, that’s a different story! That’s a self-reinforcing, virtuous cycle. The fact is, ANYTHING is possible with enough practice and consistent effort.

Anyway, that’s my positive thought for this Friday. You can do ANYTHING if you set yourself up for success, one habit at a time.

Want video or audio of this? Check out our podcast using Apple, Google, or the podcast host of your choice – and also on my Youtube channel. And, of course, there’s more like this in my book. Enjoy!

Interview with Abel Wang – Part 3!

On our podcast this week, we get a chance to chat with one of my good friends Abel Wang from Microsoft. This one was so GOOD we had to stretch it out into three parts to make it fit our podcast. You’re gonna love it! (Click the links here for Part 1, Part 2, and Part 3)

Check out Part 1 and Part 2 for more… but this discussion is muy caliente! We talk about testing, the power of feature flags (Abel’s a tireless advocate for LaunchDarkly, one of our faves), how eliminating flaky tests is key, and Dynatrace.

  • [1:00] – The power of feature flags
  • [3:03] – Capability matrixes
  • [6:00] – “Quality used to be something we just worried about at the end of the project… You just can’t move at speed without unit testing!”
  • [9:41] – Unit tests are for regression errors.
  • [12:08] – killing flaky tests – is a “red” build really red?
  • [15:00] – Azure DevOps’ unique advantage in dogfooding – we can be our own guinea pigs with release rings!
  • [19:10] – Dynatrace and the unbreakable release pipeline – using AI to catch and roll back on issues quickly
  • [20:55] – What does the future hold? We look into a crystal ball and think about where we’ll be in 10 years.
  • [22:50] – Is lift and shift an antipattern?

 

Click below to check out the podcast. We’re on all the major platforms now, including Anchor, Apple, Google, Spotify, PocketCasts, and RadioPublic.

 

Links to live by: