DevOps is a state of mind, that's all... you can go in peace now. Just kidding, it isn't, and if it were we could all do some yoga and meditation and everything would be solved. So, let's begin.

One of the things that I wondered the most even before joining Microsoft was what the #$@! was DevOps. The first time I heard someone talk about it I thought it was a job title, a mix between a Developer and an IT Ops guy, so the companies could need fewer people. Then after attending some events, my head was it's all about automating things, no people involved at all, damn we gonna lose our jobs!. I've seen organizations giving people the title DevOps engineer, others told me it's a certification you earn once you pass an exam.

The good thing (and bad also) is that DevOps is like this giant building you stand next to, depending on where you are standing it's what you really see. If you're a developer, you probably gonna look at DevOps as automated builds, having a nice and healthy Continuous Integration(CI) and automated tests.
If you more an Operations person, you gonna probably see DevOps as implementing infrastructure as code (IaC), Continuous Deployment (CD), and if you come from the dark side (aka as Project Manager) it's all about agile and scrum.

Well... then I'm more confused than when I entered this clickbait post!
Luckily, Microsoft decided to gather all essential aspects of DevOps in one single definition. Donovan Brown, Cloud Advocate Manager of Methods and Practices, came out with:

DevOps is the union of people, processes, and products to enable continuous delivery of value to our end users.

The most important part of this definition is, do you guess it? maybe it's people, yeah... we're super important, and the hardest part of it. Maybe it's the products we use, yeah you have to choose some technologies to be productive, but no, those are not the most important.

The most important word from the definitions is Value, why? because that's our end goal, it's not to finish our backlog items in a Sprint, it's not to deliver a new feature. It is to deliver value to our end users, and we can do that without changing a line of code.

Think of this, me as a developer... I spend 4 months developing a new feature, I work as hard as I can to meet the deadline, work after hours, even really, having poor sleeping, solving those bugs!, I really commit to finishing these User Stories. I finally do, commit push last changes, happiness, leave instructions for Operations team to install the feature on QA and then Production.

Months later, I hear from my manager, "Hey! we need to talk... looks like no one is using our awesome new feature that you really worked hard on these past months". Has this happened to you before?, leave a comment in discussion

So shipping new features doesn't really mean shipping value. How do we overcome this type of situation?

Remember the definition of DevOps? it consists of 3 main components: People, Process and Products. Let's overview each one of them.

People

Remember that I told you that People are the hardest part of the definition of DevOps? That's why we are unique, we are super complex, and we don't want to learn more things! for the sake of dog, I'll explode if I have to learn a new Mobile Framework.

But how do we work? Developers really try hard creating new features, trying to get into production, they're encouraged to change things. While in the other hand we have Ops teams, they are the OPPOSITE side of things, they're encouraged to maintain servers up & running, healthy machines, so... they're not going to let you go into production, because the last time you changed something, you broke it and we were unable to serve customers for hours!

We have to change the way we encourage people end goals, deliver value to our customers and end-users! When both, developers and operations start focusing on the same goals, they start working together.

Process

In order to work together, you're going to need to adopt some processes for continuous collaboration:

Plan

You need to plan your work, gather your team of highly creative and committed members, business people, devs, everyone is invited. Transform business ideas into Epics, Features and User Stories, create your product backlog and keep tracking of those tasks, while you keep discovering new features to keep delivering value to your customers.

Nowadays products and services are never-ending stories, they evolve iteration by iteration. I highly recommend you invest some time to dive into the Agile work process and the Scrum Framework, in the end what we do is a team sport!

Develop & Test

Once you have your idea you’ll need to develop it in some technology stack, preferably Microservices with .NET Core on Azure with AKS, just kidding. Choose whatever you like and need, but keep in mind some considerations.

Code versioning, choose a code repo host like GitHub to keep tracking of your code changes. Establish practices like Peer Code Review, Choose a branching strategy like maintain in a master branch just what is ready to production, and have a pseudo master branch per sprint, or having a branch per feature.

Continuous Integration meaning that you automatically compile your code every time you make a change, so you know that what you’re building is not breaking and when it breaks you already know and it gets easier to find who made the change and where it fails.

Also try to adopt testing practices like Unit Testing, Integration Test and UI testing. I always recommend taking the time to dive into Test Driven Development (TDD) to ensure software quality. You can automate all your testing as part of your CI pipeline so that every time you compile the app you also test it to maintain the quality of your software.

Release

Once you start building those small packages of value, you will want to start delivering those changes to different environments, like dev, staging, QA and Prod, among others. You can have as many environments as you and the business needs.

An important part of this process is having as much as automated tasks, so you don't mess up everything. You really tried hard on building new features and creating bug free code, so why messing it up by not compiling things right, or by copying files manually, when you can have automated tasks that build and deploy the app for you and you just realize it's deployed when you receive an email with Subject: "Deployment Succeed!".

You can achieve this by having a Continuous Deployment Pipeline (CD), with automated tasks that describe how to install your app on different stages. Inside this you can have integration testing, automated functional tests, even have some automated deployment on just some stages, and in others manual approval, so your boss can press that green button to go to Production. You have a LOT of things to have fun and try on this phase.

In my experience a very basic or common scenario is having an automated deployment on Dev environment, so you'll always know how things are working as you make changes. On QA environment you'll have automated deployment with some release gates, meaning you should have automated test looking for open bugs or measure your Server/Cloud service performance. And for stagings and Production stages you would have a mix of automated tasks and manual approval by the business people.

Well, you already planned your app, developed it and deployed into production... we're done, right? we delivered value, right? We're not done yet.

Monitor & Learn

This process is super crucial, as much as important as every other process we already reviewed. You must monitor what you already delivered, track your users and understand them. Most of Apps ideas fail mostly because they never understood their users, look at what features users use the most and focus your efforts in those, if your users are not using something, maybe it's time to rethink it or maybe stop wasting time on that feature and move to the other.

It's crucial to learn from these data insights, you can collect a lot interesting of data from your apps, like in which time are features used, on which countries, what devices are using your apps, which buttons and functionalities are pressed, what is failing, and what is not used.

Repeat

Probably you get the idea from the title, all these processes become a cycle, after you get insights and feedback from users you can plan new ideas and changes, develop them, test them and so on. People and technologies change, so your apps should and evolve with them.

Products

In order to materialize what we talked about before, you're going to need some products or technologies. There are A TON of colors and flavors to choose from. Just to name a few, for planning: Jira or Azure Boards, Develop: Visual Studio Code, Azure, GitHub, GitLab. For Release Jenkins, Chef, Puppet or Azure Pipelines, and monitoring Azure Monitor, again, there are a ton of tools to choose from, these are just a few examples.

My personal favorite is Azure for app muscle and computing power, Visual Studio & VS Code as IDE, GitHub for my repos and Azure DevOps to everything related to Plan, Develop, Test, Release and Monitor, in future posts I hope to go deeper on some of these tools.

Closing up

DevOps is here to stay, your competition is already doing it, we need to work as teams and start collaborating, we must stop being separate organizational Silos who fight each other, or we're going to lose in the hands of the ones that are changing.

Thank you so much for getting all over here, I hope you find this interesting, catch me on the next episode of What the 🤬 is DevOps