DEV Community: Mauricio Contreras

What the 🤬 is DevOps: Continuos Integration with Azure DevOps 👨‍💻✔

Mauricio Contreras — Wed, 27 Nov 2019 02:39:50 +0000

Hey there! If you haven't checked out the previous post from this series, I highly recommend it to get a bigger picture.

Introduction

Let's say that you and your team are developing the most awesome app from all times... it's Friday 5 PM, and one of your coworkers is going to miss a very important heavy metal show if he stays one more minute at the office, so he commits his work and pushes to master.

Then... next Monday at 9 AM your boss enters the office jelling, WHO BROKE IT! everyone starts looking at the commit history, one by one, reverting, resetting, compiling different versions from the branches, after 4 exhausting hours they found out... it was the heavy metal guy, who pushed to master without even compiling his code that Friday.

This is wrong in so many ways, just to point a few, first, why the heck your boss is an angry panda? now... seriously, you should never commit something anywhere without even testing locally on your machine. If it doesn't work on your machine don't expect to magically work somewhere else.

Nobody should be able to push directly to master without passing some kind of test and, reviews and final approvement, you should have a branching strategy that is clear and known by all team members.

But we can do this better and in fact, be able to deliver our code faster and safer.

What is Continuous Integration?

In Sam Guckenheimer words

Continuous Integration (CI) is the process of automating the build and testing of code every time a team member commits changes to version control. CI encourages developers to share their code and unit tests by merging their changes into a shared version control repository after every small task completion. Committing code triggers an automated build system to grab the latest code from the shared repository and to build, test, and validate the full master branch (also known as the trunk or main).

So the whole idea of having Continuous Integration is that you're always compiling your app as your Code Repository changes, so everyone knows if something fails, you can figure out which change broke the code, who pushed the changes, find the error and solve it faster.

Adopting DevOps practices won't avoid failure, you got it wrong if you thought that by adopting DevOps practices nothing is going to go wrong, instead... you're more common to be failing more than before, but you'll fail FASTER and you learn faster too.

Getting Started

As we have discussed before, there are several colors and flavors of tools and products made to help you adopting DevOps practices such as Continuous Integration, but we will be using Azure DevOps, which is what I like the most.

But, what is Azure DevOps?

Azure DevOps is Microsoft's collection of Services to take your ideas into production. It has everything you need to plan and organize your work with Azure Boards, a single source for all your repositories in Azure Repos, a great CI/CD service Azure Pipelines,

You don't have to use all of this, you can pick whatever service you may need, if you already have your source code somewhere else like Gitlab, you don't have to use Azure Repos, or maybe you or your company already invested in a CI/CD automation technology, again you don't have to use Azure Pipelines. Just pick what you need, they work great by themselves, but when you use altogether, you can have the best traceability of your code, you can find a bug and solve it in record time.

Demo Scenario

We are going to create a CI pipeline for an application built upon ASP.NET and React, every time we make a change to our code repo, we're going to build a Docker image.

Pre-requisites

Azure Subscription
- Don't have one yet? create an Azure subscription for free. Get credits that can be used to try paid Azure services. Once you consume all your credits you can keep the account and use all free Azure services and features.
- If you are Visual Studio subscriber, claim your benefits. Visual Studio subscription gives access to monthly credits that you can use on Azure services.
- Are you student? Create an Azure Student Account and get free credits.
GitHub account

Let's create our first Build Pipeline

First, we need some code and a repository to work with, I'll be using GitHub as my code repository to show you that you don't have to use Azure Repos if you already have an existing repository.

For this demo I'll be using Microsoft's TailwindTraders Open Source project, it's a fictitious e-shop that you can contribute to on GitHub. check the live running website.

Make sure to fork the repo to follow along

microsoft / TailwindTraders-Website

Tailwind Traders Website

Repositories

For this demo reference, we built several consumer and line-of-business applications and a set of backend services. You can find all repositories in the following locations:

Deploy to Azure

With the following ARM template you can automate the creation of the resources for this website.

When you deploy this website to Azure you can define the Backend you want to use in case you have deploy your own backend. By defaults it is configured the public Backend environment provided by Microsoft.

Note: you can change the InstrumentationKey of the Application Insight that is configured by default.

If you want to update the application to use your own backend, set apiBaseUrl parameter on the ARM template provided to the url where your aks is configured.

…

View on GitHub

You could just go to Azure Pipelines and create a Build Pipeline in dev.azure.com but today we will start from GitHub to show this great experience.

Navigate to GitHub's Marketplace and search for Azure Pipelines (not Actions, we will talk about it in next posts)

Then install the extension and grant it access to your existing repository.

Now we need to assign an Organization and project if you don't have any you can totally create them at this step. Keep in mind that Organizations are just groupings of Projects, you can have many projects inside an organization.

Note that Azure Pipelines already knows that we want to integrate our repository from GitHub, this is because we used the extension from GitHub's Marketplace, so select your repo.

It is time to create our build definition! Azure DevOps by default offers a lot of different Templates ready to use so we can have the option to not start from scratch, and be more productive.

Select or search the Docker Template

It will ask you to specify your app's Dockerfile path, but what is a Dockerfile, to put it simply, a Dockerfile is a like a cookbook recipe instruction, where it specifies each step in order to compile your application. Our project already has a Dockerfile, that specifies tasks like copying directories, and running commands such as npm and dotnet, it also specifies which Docker image to use, in this case, Docker Alpine.

FROM node:10-alpine as build-node
WORKDIR /ClientApp
COPY ClientApp/package.json .
COPY ClientApp/package-lock.json .
RUN npm install
COPY ClientApp/ . 
RUN npm run build

FROM microsoft/dotnet:2.2.100-preview3-sdk-stretch as build-net
ENV BuildingDocker true
ENV ASPNETCORE_ENVIRONMENT=Development
WORKDIR /app
COPY *.csproj .
RUN dotnet restore
COPY . .
RUN dotnet build
RUN dotnet publish -o /ttweb

FROM microsoft/dotnet:2.1-aspnetcore-runtime as runtime
WORKDIR /web
COPY --from=build-net /ttweb .
COPY --from=build-node /ClientApp/build ./ClientApp/build
ENTRYPOINT [ "dotnet","Tailwind.Traders.Web.dll" ]

for our project the path is Source/Tailwind.Traders.Web/Dockerfile

Click Validate and configure and it will generate the following YAML definition for your Build Pipeline, it contains every step that your CI is going to execute in order to compile your application, in our case we just need one task, Docker build, specifying our Dockerfile path.

Your YAML code should look like this

# Docker
# Build a Docker image 
# https://docs.microsoft.com/azure/devops/pipelines/languages/docker

trigger:
- master

resources:
- repo: self

variables:
  tag: '$(Build.BuildId)'

stages:
- stage: Build
  displayName: Build image
  jobs:  
  - job: Build
    displayName: Build
    pool:
      vmImage: 'ubuntu-latest'
    steps:
    - task: Docker@2
      displayName: Build an image
      inputs:
        command: build
        dockerfile: 'Source/Tailwind.Traders.Web/Dockerfile'
        tags: |
          $(tag)

Once we click save, it will ask if you want to directly commit to master branch or create a Pull Request, I don't mind pushing code to master in my own demo, but if you're working on a real project, go should for the Pull Request 😁

It will keep your Build Pipeline together with your application code, meaning, this has some cool advantages, for example, you can make Code Review over the Build Pipeline if someone modifies it, and ask questions about it. Another reason is that the code and how to compile the code will live together. If someone new is onboarding your project he won't have any problems trying to get it working.

Once you hit Save it will start working on your pipeline tasks, such as preparing the job, downloading the source code and compiling with our Yaml definition. You can now go and prepare some coffee, or enjoy the view looking at the output window.

If everything goes as expected, when you come back you'll get a nice overview of every task marked with a green ticket ✔, and a pretty email in your inbox saying that the [Build succeeded] yay! 🙌

Congratulations! 🎉 you just Setup Continuous Integration for your project! So what would happen now? For every committed change coming to our master branch, there will be a new Build triggered, ensuring that what we're sending to our repo is not breaking our app.

Let's make a change!

Go to your Build Pipeline and click on the three dots button, you'll see an option called Status badge, it's an indicator that you can show off on your project readme file to let everyone know about the Build status.

Copy the Sample Markdown and paste it on your README.md file, commit that change to your repository and see what happens on your Build Pipeline.

Voilà! Now you have Continuous Integration for your GitHub project!

Summary

We started talking about the problems that come with not having Continuous Integration for our projects, we covered some concepts behind CI, and why it's important on DevOps.

I introduced to you Azure DevOps, we just moved around in one specific service, Azure Pipelines, and to be more specific, Build Pipelines which is our CI.
We took an existing application written in ASP.NET and React, and built a simple Pipeline using the Docker Template in just minutes.

Finally, after setting up our CI, we tested that seconds after committing new code on GitHub it automatically triggered a new Build on Azure DevOps, completing our CI cycle.

This is just a simple demo, this is not a production-ready CI by no means, but I hope it helps you to get started.

Next steps

In the next episode, we will cover how to take what we just compiled, and deliver it to Azure through a Release Pipeline 🚀☁ as we deep dive into Continuous Delivery, stay tuned!

Increasing your .NET Core App's Resilience: Building a Faulting API

Mauricio Contreras — Tue, 19 Nov 2019 18:53:34 +0000

Introduction

Imagine you're building an app that depends heavily on consuming some API that you don't own. How do you handle errors while making requests? Maybe the API couldn't respond for a couple of seconds, and now it's working again (transient errors), or maybe the service is down and no answer will be given back for a while.

We will be covering both scenarios on this post series, we will be simulating a faulting API that responds correctly a couple of times and then stops working for a predefined time and we will look at how to implement a retry mechanism to try sending a request again and what to do if the service does not respond after some failed intents.

So let's start coding!

I created this sample using the .NET Core API Template from Visual Studio 2019, the "Weather Forecast".

Our sample uses AspNetCoreRateLimit nuget to restrict API calls by IP to simulate the "Out of service" state. You should definitely check it out, it has different ways to restrict API calls, and it's easy to get it to work.

Once you installed the NuGet library you can add it to your Startup.cs

// This method gets called by the runtime. Use this method to add services to the container.
public void ConfigureServices(IServiceCollection services)
{
    // needed to load configuration from appsettings.json
    services.AddOptions();

    // needed to store rate limit counters and ip rules
    services.AddMemoryCache();

    //load general configuration from appsettings.json
    services.Configure<IpRateLimitOptions>(Configuration.GetSection("IpRateLimiting"));

    //load ip rules from appsettings.json
    services.Configure<IpRateLimitPolicies>(Configuration.GetSection("IpRateLimitPolicies"));

    // inject counter and rules stores
    services.AddSingleton<IIpPolicyStore, MemoryCacheIpPolicyStore>();
    services.AddSingleton<IRateLimitCounterStore, MemoryCacheRateLimitCounterStore>();

    // https://github.com/aspnet/Hosting/issues/793
    // the IHttpContextAccessor service is not registered by default.
    // the clientId/clientIp resolvers use it.
    services.AddSingleton<IHttpContextAccessor, HttpContextAccessor>();

    // configuration (resolvers, counter key builders)
    services.AddSingleton<IRateLimitConfiguration, RateLimitConfiguration>();

    services.AddControllers();
}

Don't forget to also add app.UseIpRateLimiting(); to your Configure Method, mine looks like this:

// This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
        public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
        {
            if (env.IsDevelopment())
            {
                app.UseDeveloperExceptionPage();
            }

            app.UseIpRateLimiting();

            app.UseHttpsRedirection();

            app.UseRouting();

            app.UseAuthorization();

            app.UseEndpoints(endpoints =>
            {
                endpoints.MapControllers();
            });
        }

After setting up everything you can go and modify your API's appsettings.json and add the following:

btw: don't forget to modify the appsettings.Development.json as I always do

  "IpRateLimiting": {
    "EnableEndpointRateLimiting": false,
    "StackBlockedRequests": false,
    "RealIpHeader": "X-Real-IP",
    "ClientIdHeader": "X-ClientId",
    "HttpStatusCode": 500,
    "QuotaExceededMessage": "Oops, Something very bad went wrong and the server couldn't respond.",
    "GeneralRules": [
      {
        "Endpoint": "*",
        "Period": "5s",
        "Limit": 3
      }
    ]
  }

This will be the IpRateLimit that will be used on the services you just defined on startup.cs, it will Limit the APIs calls to 3 requests per 5 seconds only. If you receive a 4th request in between those 5 seconds, you'll get a 500 error (you can set whatever HtppStatusCode you want) and a message with a response of "Oops, Something very bad went wrong and the server couldn't respond."

Note that in GeneralRules you can add as many rules you want, in my case for this demo purposes I just declared that I would apply one rule to all my endpoints "Endpoint": "*", but you can create rules for one specific endpoint like "Endpoint": "get:/api/values".

That would be for our faulting API. You can now manually test the endpoint to check how it behaves.

Now let's work on our client app that will consume the faulting API.

We will be creating a .NET Core 3.0 Worker Service that will be making requests repeatedly to our faulting API and printing on the console all the results.

For that, I started by creating a new project from the template 'Worker Service'.

Then at Program.cs at the CreateHostBuilder method, we add the HttpClientFactory service for our API Requests.

services.AddHttpClient<Worker>();

Our Program class should look like this:

using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

namespace NETCore_ClientConsole
{
    public class Program
    {
        public static void Main(string[] args)
        {
            CreateHostBuilder(args).Build().Run();
        }

        public static IHostBuilder CreateHostBuilder(string[] args) =>
            Host.CreateDefaultBuilder(args)
                .ConfigureServices((hostContext, services) =>
                {
                    services.AddHttpClient();
                    services.AddHostedService<Worker>();
                });
    }
}

Now we need to edit our Worker.cs class

First, we need to create a new variable for our Client Factory

private readonly IHttpClientFactory _clientFactory;

Then we can inject it to our Worker constructor like this:

public Worker(ILogger<Worker> logger, IHttpClientFactory clientFactory)
{
    _logger = logger;
    _clientFactory = clientFactory;
}

Note that our Worker class inherits from BackgroundService, it will let us override some methods that we need for execution such as StartAsync, StopAsync, and ExecuteAsync.

We need to override the StartAsync method to create our Http Client, like this:

   public override Task StartAsync(CancellationToken cancellationToken)
        {
            client = _clientFactory.CreateClient();
            return base.StartAsync(cancellationToken);
        }

We already defined that every time the service starts it should create our Http Client, but what if our service stops, for that, we need to override the StopAsync method, we need to tell the service that when it stops, it also Disposes our Http Client.

public override Task StopAsync(CancellationToken cancellationToken)
        {
            client.Dispose();
            return base.StopAsync(cancellationToken);
        }

And finally, we implement our logic in the ExecuteAsync task, it will make repeatedly request calls delayed by 1 second to our Faulting API that we created previously http://localhost:59316/weatherforecast while we don't stop the process.

If the request success, we will log a message letting us know that our API responded ok. If not, it will log a Request Failed message with the respective code status. (Remember we defined that it should be a 500 code status?)

protected override async Task ExecuteAsync(CancellationToken stoppingToken)
        {
            while (!stoppingToken.IsCancellationRequested)
            {
                var result = await client.GetAsync("http://localhost:59316/weatherforecast");
                if (result.IsSuccessStatusCode)
                {
                    _logger.LogInformation($"Request Succeed with code status: {result.StatusCode}");
                }
                else
                {
                    _logger.LogInformation($"Request Failed with code status: {result.StatusCode}");
                }
                await Task.Delay(1000, stoppingToken);
            }
        }

Our final Worker class should look like this:

using System.Net.Http;
using System.Threading;
using System.Threading.Tasks;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;

namespace NETCore_ClientConsole
{
    public class Worker : BackgroundService
    {
        private readonly ILogger<Worker> _logger;
        private readonly IHttpClientFactory _clientFactory;
        private HttpClient client;

        public Worker(ILogger<Worker> logger, IHttpClientFactory clientFactory)
        {
            _logger = logger;
            _clientFactory = clientFactory;
        }

        public override Task StartAsync(CancellationToken cancellationToken)
        {
            client = _clientFactory.CreateClient();
            return base.StartAsync(cancellationToken);
        }

        public override Task StopAsync(CancellationToken cancellationToken)
        {
            client.Dispose();
            return base.StopAsync(cancellationToken);
        }

        protected override async Task ExecuteAsync(CancellationToken stoppingToken)
        {
            while (!stoppingToken.IsCancellationRequested)
            {
                var result = await client.GetAsync("http://localhost:59316/weatherforecast");
                if (result.IsSuccessStatusCode)
                {
                    _logger.LogInformation($"Request Succeed with code status: {result.StatusCode}");
                }
                else
                {
                    _logger.LogInformation($"Request Failed with code status: {result.StatusCode}");
                }
                await Task.Delay(1000, stoppingToken);
            }
        }
    }
}

We did it! now you can run our Worker Service by hitting F5!
psst! don't forget to set up both projects, the API and the Service.

Summary

That's all for now! you already learned to create a Faulting API by restricting incoming API calls and responding with different HTTP responses.
Also, we created a Worker Service client to consume our API and see how it behaves after several API calls.

I hope you enjoyed this as much as me while writing this.
In the next chapter I'll be adding different Resilience patterns to our client like Retry and Circuit Breaker, so Subscribe!

You can find the full working sample at GitHub ❤

maurobytes / NETCore-FaultingAPI

.NET Core 3.0 API throttled on purpose with Worker Service as a client application

ASP.NETCore Resilience Sample

This sample demonstrates how to create a Faulting Web API utilizing .NET Core 3.0 and a throttling library.

The solution has two projects, the Faulting API itself and a Worker Service that calls the API to make repeated requests and logs the responses obtained.

You can follow along this post I made at the Dev Community to learn how I built this sample

This sample was made with:

View on GitHub

What’s the most painful part of DevOps for you as a developer?

Mauricio Contreras — Fri, 15 Nov 2019 15:58:42 +0000

Are you working on a team that is adopting DevOps? what hurts the most? Maybe for you it is that there are too many tools, or maybe you find too difficult to build a CI/CD workflow. Let's discuss your personal experience ✌

What the 🤬 is DevOps: People, Process and Products

Mauricio Contreras — Fri, 15 Nov 2019 01:37:27 +0000

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