DevOps on Wesley Camargo

This is what you should do to make your CI/CD more secure

Wed, 14 Jun 2023 18:04:59 +0200

This is what you should do to make your CI/CD more secure

Security is now a trending topic in the IT industry, with data leaks and breaches happening left and right, so it’s super important to tackle any risks in our environments. One of these risks is the management of Service Principal secrets to connect to workloads running outside Azure, such as other clouds or external CI/CD tools. In this post, we will learn how to use Workload Identity Federation to tackle this and make our DevOps process more secure and efficient.

Making your CI/CD more secure with Passwordless Authentication on Azure

Photo by regularguy.eth on Unsplash

Pre-requisites

Azure Service Principal Name or Azure Managed Identity
GitLab repository

What is Workload Identity Federation?

WIF (Windows Identity Foundation) enables passwordless authentication, granting access to Azure AD and Azure Resources without the need to manage secrets or certificates.

Once configured, you establish trust with an external OpenID Connect (OIDC) identity provider such as GitHub, GitLab, Kubernetes, Google, and AWS, also known as **Issuer. **It is also necessary to provide the Subject Identifier, so Azure AD will be able to identify the resource when attempting to log in and establish a connection with the external application.

How to setup Workload Identity Federation on Azure

The process to set up is quite simple but requires permissions to manipulate Azure AD identities. It consists of appending an existing AAD, which can be a Service Principal or a Managed Identity with a Federated Credential.

In our example, I will configure it in a GitLab pipeline.

To do so, it is necessary to inform

Issuer: The Identity Provider, in our case [https://gitlab.com](https://gitlab.com)
Subject Identifier: In the case of a GitLab pipeline, the repository name project_path:<project>/<repo name>:ref_type:branch:ref:main
Audience: Service account tokens [https://gitlab.com](https://gitlab.com)

Creating an Azure User Managed Identity

If you don’t have a Service Principal or Managed Identity in place yet, you can run the Azure CLI script below. It creates the MI and sets Contributor permission in the current subscription.

The script will also print out the TenantId a ClientID that will be necessary to connect on the GitLab pipeline.

Setting up an Azure Federated Credential

The script below creates the Federated Credential in an existing Manage Identity. It can also be replaced by a Service Principal.

Configuring GitLab CI/CD Settings

On the GitLab side, you just need to inform the TenantId and ClientId that were prompted in the creation of the Managed Identity.

The pipeline below demonstrates how to connect and create a resource group in an Azure Subscription:

After running the pipeline, you can see that the connection was successful:

👋 If you find this helpful, please click the clap 👏 button below a few times to show your support for the author 👇

🚀Join FAUN Developer Community & Get Similar Stories in your Inbox Each Week

Stop breaking your environment: How to get started with Azure DevOps Pipelines

Mon, 07 Nov 2022 15:17:27 +0100

Stop breaking your environment: How to get started with Azure DevOps Pipelines

Have you ever had problems with manual deployments? It is not about if but when an error will happen. I even saw entire sites being replaced wrongly! It is scary, isn’t it? Azure DevOps Pipelines will help you to avoid such mistakes, so check on this post how to deploy your application in minutes, taking advantage of all benefits that automated pipelines can bring to you!

Photo by Louis Hansel on Unsplash

What is Azure DevOps Pipelines?

A Deployment Pipeline is an automated process that combines Continuous Integration (CI) and Continuous Delivery (CD), deploying your application in a given environment. In other words, it automatically builds, tests, and deploys your code to make them available to other people.

Prerequisites

Before we start creating the pipelines, there are configurations that we need to prepare in advance. My friend Jev Suchoi and I have already created a series of posts covering all these topics:

How to create an Azure DevOps organization
How to configure your Azure DevOps project
[Basic git commands you need to know](http://Git Basic commands in a nutshell)
Pushing code to git
Connecting Azure DevOps with Azure
Creating a variable group on Azure DevOps

How to create an Azure DevOps pipeline

Azure DevOps Pipelines are an implementation of deployment pipelines that supports multiple programming languages and clouds. Basically, everything can be deployed using this tool.

So let’s create our first pipeline!

First of all, we need our application under a Version Control System. In this post, I showed how to create a local repository for a dotnet core application, and **here **I show how to push the code to a remote repository on Azure Repos.

With the repo in place, go to Pipelines on the left menu, and then click on New pipeline:

Image by Author

In the new window, choose your repository. In this example we are using the Azure Repo that we created on the post mentioned above:

Image by Author

Choose the **Starter pipeline. **If you already have your own YAML, you can choose the Existing option.

Image by Author

Azure DevOps Pipeline anatomy

Azure DevOps will create a skeleton of a pipeline. It is quite simple, but enough to start. Let’s see what we have there:

**Trigger — **This is the configuration about which branch(or branches) our pipeline will be triggered if we have new commits. Normally this is tied to your branch strategy, by default it is created to the default branch in the chosen repository.
**Pool **— The pools are a set of machines that run our build inside. Azure DevOps has two pools when it’s created. The **Default **is a pool in which you can add your own agents. **Azure Pipelines **on the other hand is a SaaS agent that Microsoft provisions.
**Steps **— Finally it starts to be fun, we have the steps! They are instructions that we send to agents in order to complete our pipeline. In some cases, they can be simple command-line scripts, but we can also make use of “packaged scripts” in the Microsoft marketplace, also known as Tasks.

Image by Author

To prepare the pipeline for dotnet core, we will change the pool to windows-latest, as I am using a Windows machine, I want to keep the same.

And we will also use a dotnet core task, with the publish command. It will prepare all the artifacts necessary to deploy our application.

In the next step, we will use an Azure Web App task, that will deploy in deploy in App Service previously created in Azure. Pay attention that a service connection is required here, so make sure that the name matches yours.

Below there is all you need to create this pipeline. Simply delete the content created automatically and replace it.

How to create an Azure DevOps pipeline with stages

Now let’s make it a bit more complex :). The pipeline above will cover some simple scenarios, mostly for testing and learning. However, if you need something more robust, you will need to organize it in a better way.

There are two resources on Azure Pipelines that will enable it: Stages and jobs.

What are Jobs in Azure DevOps?

In a few words, **Jobs **are sets of **Steps **that run together. Every pipeline has at least one job, even if you do not specify one, by default your steps will be encapsulated in a job.

There are multiple scenarios where the use of multiple jobs is beneficial, as per separate responsibilities, running different jobs in parallel, and so on.

There is one special type of job for deployments. It is recommended to use it as brings some benefits as Deployment history and the possibility to use pre-configured strategies, such as canary, blue-green, etc.

To specify a job, you can simply add this to your pipeline:

What are Stages in Azure DevOps?

As we saw above that Jobs are sets of Steps, so guess what? Stages are sets of… Jobs!

To determine the boundaries of your deployment, pausing and validating before moving on, Stages must be used.

I recommend structuring your pipelines in the following manner:

One stage to gather all artifacts that will be used during the deployment, also known as a “build stage” (in some cases, you don’t need a real build generating binaries, as some languages don’t produce them, as IaC languages or even PHP for example).
Different deployment stages for different environments, for example, Development, UAT, and Production. It will allow you to validate the quality of your code during the journey toward production.

The stage structure is similar to the job syntax, and contains one or more jobs:

Below we can see the conversion of the simple pipeline to a complete pipeline using **Jobs **and Stages:

Key takeaways

Azure Pipelines is a powerful and very flexible tool that can technically support all programming languages, clouds, and technologies. It is part of Azure DevOps ecosystem, having native integration with with the other tools, do not require external integrations, however it also supports if required, and it makes quite easy to configure and increase productivity from the first moment you start to use it.

I hope this would help you, and see you in the next post!

👋 If you find this helpful, please click the clap 👏 button below a few times to show your support for the author 👇

🚀Join FAUN Developer Community & Get Similar Stories in your Inbox Each Week

How to deploy Management Groups with Azure Bicep and Azure DevOps

Mon, 26 Sep 2022 15:04:40 +0200

How to deploy Management Groups with Azure Bicep and Azure DevOps

If you have several Subscriptions on your Azure Tenant, Management Groups can be very handy to organize them. Check in this post, on how to deploy Management Groups using Azure Bicep.

Photo by Ian Battaglia on Unsplash

What are Azure Scopes?

According to official Microsoft documentation “Scope is the set of resources that access applies to.” This is used to have granularity when assigning permission in your Azure resources. The majority of Azure resources are deployed into the Resource Group scope, and when we use Azure bicep, this is the default. But there are four levels of scopes in Azure as we can see in the image below:

Azure Scope levels — Image from Microsoft Docs

With that said, when we are deploying a resource different than those deployed at the resource level, we need to specify against which scope we are running it. For Management groups, the scope must be the **tenant. **In the following sessions, we will see how to set it up.

Bicep scope to deploy Azure Management Groups

As said before, the default scope in an Azure Bicep script is the resource group. For most traditional resources such as App Services, or Storage Accounts, it is not necessary to specify it, but to deploy management groups it is necessary to specify the tenant as the target scope:

Image prepared by Author

Below it’s possible to see the code necessary for the most basic creation of a Management Group:

How to call an Azure Bicep template at the Management Group scope with Azure CLI and Azure DevOps YAML pipelines

To run deployments against tenant scope it is also necessary to specify it in Azure CLI

Below there is an Azure DevOps YAML pipeline with the task configured to deploy the bicep file created above:

SPN permissions to deploy Azure Management Groups

By default, the Service Principal Name does not have permission to deploy tenant resources. You need to grant it at the root scope “/” to make it work.

In this case, the error below will show up:

ash AuthorizationFailed: The client with object id does not have authorization to perform action 'Microsoft.Resources/deployments/validate/action' over scope '/providers/Microsoft.Resources/deployments/main' or the scope is invalid.

How to elevate user permissions as Azure AD Global Administrator

First, you need to elevate your permissions as user Global Administrator into Azure AD:

How to grant Service Principal Name permissions to deploy Azure Management Groups

After setting up your permissions as Global Administrator, you are able to set your SPN with the correct permissions:

The best Azure Management Groups naming convention

It is also crucial to properly name your Management Groups, making them easy to maintain, especially if you are adopting Infrastructure as Code with automated pipelines. Also, if you have multiple directories, you also need to efficiently identify which directory a particular management group belongs to.

My friend @DevJevNL has an excellent proposal to tackle the naming convention in a series of posts, here is his suggestion for Management Groups.

Conclusion

Although it is a very simple process, there are some tricks to deploying management groups. In this post, I tried to clarify all the necessary steps to deploy it. Below it is possible to visualize the management group deployed in our Azure Tenant.

Image prepared by Author

References

https://learn.microsoft.com/en-us/azure/role-based-access-control/elevate-access-global-admin Enterprise-Scale/EnterpriseScale-Setup-azure.md at main · Azure/Enterprise-Scale *This article will guide you through the process of configuring permissions in your Azure environment to enable ARM…*github.com

Creating and publishing PowerShell Modules to Azure Artifacts with Azure DevOps YAML Pipelines

Thu, 03 Feb 2022 00:02:46 +0100

Creating and publishing PowerShell Modules to Azure Artifacts with Azure DevOps YAML Pipelines

PowerShell Modules are very useful and can save a lot of time if well designed and created. Check on this post how to create and pack a basic PowerShell Module, and publish it into Azure Artifact using Azure DevOps YAML Pipelines.

Photo by Trnava University on Unsplash

Creating PowerShell Module and PowerShell Module Manifest

Creating a PowerShell Module - psm1

A PowerShell Module is a way to organize and pack a set of PowerShell components to be reused or shared. The most common components to be shared are functions.

In this example, we will create the module Example.Module with the extension psm1 , and include a PowerShell function.

Creating a PowerShell Module Manifest - psd1

To create the Module Manifest, it is possible to run the cmdlet New-ModuleManifest . It will generate the psd1 manifest file with default configurations.

The most important variables are NestedModules and RootModule which must contain the name of the psm1 file.

Creating a nuspec file for the PowerShell Module

To create the nuspec file you need to run the command nuget spec Example.Module . It will generate a base file that it is possible to replace with your values.

Making the PowerShell Module version dynamic

In both psm1(1) and nuspec (2) files there is a variable $(version) . This variable will be replaced by the version defined in the deployment pipeline. It uses the Azure DevOps macro syntax to consume the variables.

Image by author

Creating an Azure Artifacts Feed

For instructions on how to create a feed, you can check this post where I also show how to push a dotnet Core package to Azure Artifacts:

How to send .Net Core NuGet packages to Azure Artifacts | by Wesley Camargo | Medium

Deploying PowerShell Module with Azure DevOps YAML Pipeline into Azure Artifact

Version Number to update PowerShell Module

To simplify this example, we will provide the version number of the module by Azure DevOps parameter(1). Then we populate a variable with the value of the parameter using template expression syntax(2). In a future post, I will how to bump this number automatically.

Image by author

Replacing version number in nuspec and module manifest

The next step is to replace the variable $(version) mentioned above with the version number. To do it will be used the replace token task. Note that we specify the extensions of the manifest and nuspec files.

Image by author

Packing PowerShell Module with NuGet

To pack the module is used the NuGetCommand task, and specified the nuspec file. After generating the NuGet package it will be published as a pipeline artifact - be careful not to confuse with Azure Artifacts, we are almost there but not yet :) - which will be consumed in the next stage: deployment.

Image by author

Pushing PowerShell Module to Azure Artifacts

Finally, in the deployment stage, we will push our package into our Azure Artifacts. It will also use the NuGet Command task to push it, sending the nupkg generate in the build stage. It is also necessary to provide the name of the Azure Artifacts Feed.

Image by author

Complete azure-pipelines.yml to publish PowerShell Modules to Azure Artifacts

[

](https://faun.to/bP1m5)

If this post was helpful, please click the clap 👏 button below a few times to show your support for the author 👇

Delivery as Code with Azure DevOps Release Engine

Fri, 28 Jan 2022 19:05:03 +0100

Delivery as Code with Azure DevOps Release Engine

Delivery as Code is the concept of having all necessary configurations of your delivery defined in a file, which can be kept under source control and have all good practices applied to application development over it. It ensures that your deliveries are consistent and reliable.

Photo by Jackson Hendry on Unsplash

Everything as Code

In the past years, everything is becoming “as Code”. It started with Infrastructure as Code, aka IaC, and today there are many languages supporting it, since the AWS Cloud Formation, passing through Terraform and Pulumi, that are Cloud agnostics, until the Azure ARM Templates and his newborn son Azure Bicep.

But there are also other uses of as Code, such as Database as Code, Pipelines as Code, Monitoring as Code, Security as Code, and so forth, this list is big and still growing.

Why have my definitions as code?

One of the reasons behind this is if you have the instructions to create your environment versioned, you can easily reproduce the steps to create it. Imagine that for some reason you lose your infrastructure environment, in some minutes you can spin up a new environment based on the versioned definitions.

Another reason is that as you can easily create a new environment, you can apply development good practices on it. For example, you can deploy a new environment using the versioned scripts, and run Unit Tests against it. With frameworks like Pester this is easy to implement.

What is Delivery as Code?

The advantages of having definitions under source control are clear, so why do not apply them in the Delivery of the software?

With that in mind and my passion to automate everything that I can, I started to develop an easy way to configure the releases and make them as simple as possible, based on my experience working in the DevOps field.

To configure a new delivery, instead of configuring manually or having scripts of how to implement it, you just need to inform what you need and all the complexity of the implementation will be abstracted. This is the declarative approach very keen on Infrastructure as Code, which allows you have indepotent deployments.

What is Azure DevOps Release Engine

Azure DevOps Release Engine is an approach developed to support Delivery as Code. It was built on top of Azure DevOps YAML Templates and can be used to deploy any kind of technology, with any kind of tool anywhere.

It means that you can deploy languages such as:

dotnet Core
nodeJS
Java

Using any tool like:

Azure Bicep
Terraform
Cloud Formation
Pulumi

In any platform:

Azure
AWS
VMWare
OnPremisses data centers

How does Azure DevOps Release Engine work?

Azure DevOps Release Engine was created using Azure DevOps YAML Pipelines as a support tool. It consists of a centralized repository where they centralize deployment definitions - the instructions of how to deploy - are versioned and Client/Application repositories which must have the declaration of what should be deployed.

The client application repository must have a YAML pipeline that extends from the main YAML in the centralized repository - here there is a post explaining how the extended pipelines work. The main file is responsible to parse the instructions provided and deciding which definition must be used.

Centralized Release definitions

The definitions in this repository can be reused, saving time and allowing all deployments of the same kind of component to be deployed in the same way, which leads to more consistent and less problematic releases, as the deployment instructions were well tested.

Client/Application repositories

The client repositories are the repos where your applications are versioned. It can have any sort of resource to be deployed and to consume the Release Engine you just need to create a YAML file following the Azure DevOps Release Engine schema.

How to set up Azure DevOps Release Engine?

Importing the repo into Azure DevOps

In the Azure DevOps Release Engine repository at GitHub copy the link to the repository following the sequence below:

Copy the repository URL — Image by author

Click in Import repository — Image by author

Paste the link and import — Image by author

After it you should have the repository in your Azure DevOps repos, with the structure below:

Image by author

How to set up the application to consume the Azure DevOps Release engine?

Repository structure

In a dotnet Core application repository add the file azure-pipelines.yml in the root folder, and one file corresponding to each environment that will be deployed in a “variables” directory. I recommend having the source code under a different directory to keep the repository cleaner and tidy, in my case it’s under the srcdirectory.

Image by author

Creating the azure-pipelines.yml file

This file contains all instructions on what resources need to be deployed. I will add the complete file in the end so it will be possible to just copy it ;).

“Importing” a repository in Azure DevOps — Image by author

The beginning of the file contains pipeline configurations that will be the same in most of the pipelines. The declaration of Release Engine as a repository resource is very important, as the templates will be consumed from this resource that will be “imported”.

Azure DevOps Release Engine settings

With Release Engine imported, it is necessary now to extend from the main.yml file (1). This file is basically a parser that will read the information provided as parameters and redirect to the correct file. I will deep dive into this file in future posts.

Image by author

The most important section is the parameters. This section contains all information that will be provided to the engine. As mentioned above this information will be parsed by the main file, and according to the resource types provided. call the right definition to deploy it.

**Release settings **Inside parameters, the session **settings (2) **contain the configuration of your release.

**Azure settings **In the current version, it is possible to enable or disable the deployment of your infrastructure, application, and build (3). Here it is also necessary to provide the directory of your variable files. The variables will be explained later. It is possible to provide the values straight on this file,

**Environments **It is also necessary to provide information about your Azure environment (4), such as service connection, resource group where the resources will be deployed, and so on. If the parameter **new **under resource group is provided, it will also create the resource group.

Last but not least, you must declare which environments will be deployed. The way that it was built will create exactly the same configuration for all environments, which ensures that the implementation in your production environment will follow the same steps as in the others, increasing the reliability of the delivery, as was mentioned at the beginning of this post.

Configuring resources to be deployed with Azure DevOps Release Engine

The latest section in the azure-pipelines.yml is the resource. This is a list of resources that will be deployed in this release and its configurations. In this example, we are going to deploy a dotnet Core application into an Azure Web App. Let’s go through the main items in this section:

Image by author

**name **- This is the name of the web app that will be created into Azure. This is provided through a parameter that is stored in the respective variable file of the environment that is running. It means that you can deploy in different environments like dev, uat and prd with unique names, avoiding conflicts.

**type **- The type is parsed inside the main.yml file and calls the right deployment definition for the type provided. This example is a dotnet Core application but it is possible to deploy any resource with the deployment definition already implemented on Release Engine.

runName - Run name is the name of the Azure DevOps job. This is necessary to make the run unique and have the possibility to link dependent resources.

enabled - It is possible to easily disable the deployment of this resource.

deploy.type - Inform which type of deployment it is. In this example, the dotnet Core application will be deployed into an Azure Web App.

deploy.infrastructure.servicePlanName - Similar to the name, we are informing the name of the service plan that will be used by our Azure Web App.

Configuring variables for Azure DevOps Release Engine

As mentioned before, it is necessary one variable file per environment. The variable file allows having resources with unique names in the environments.

This file will be loaded automatically by the engine, so the only action necessary is to add the file following the patter {env-name}-vars.yml, where env-name is the name defined at azure-pipelines.yml

After being loaded by the engine, the variables will be available like any other variable in Azure DevOps. In azure-pipelines the variables are accessed using the macro syntax $(variable-name).

Complete template

Below there is the complete template for dotnet Core and Azure Web Apps. You can also check the repository with more examples and the implementation of the engine on Azure DevOps Release Engine repository at GitHub.

Takeaways

The Azure DevOps Release Engine simplifies the release configuration, abstracting the release definition providing an “as Code” approach for your Delivery.

This is a work in progress but built on top of a very mature process based on real-life experience, solving real-life problems that we face in our day-by-day activities.

I hope it can help, and see you in future posts! [

](https://faun.to/bP1m5)

If this post was helpful, please click the clap 👏 button below a few times to show your support for the author 👇

How to extend an Azure DevOps YAML Pipeline Template

Thu, 30 Dec 2021 17:28:36 +0100

How to extend an Azure DevOps YAML Pipeline Template

If you need to control what is allowed during your deployment, extending the YAML Templates is the easiest way to know what is being done on your deployments.

Photo by Zonduurzaam Deventer on Unsplash

Azure DevOps YAML Templates

YAML Templates are the smartest way to create your pipelines. It allows you to break down the pipelines into small pieces reusing your logic, which leads to some best practices as Don’t Repeat Yourself and Dependency Inversion.

It’s also possible to use the *Declarative *instead of the Imperative approach, therefore who will consume your pipelines does not need to know the details of how to deploy an application, but just say what is necessary to deploy.

With these principles being correctly applied, it is possible to build a reliable and robust way to deploy new applications, but who will consume it doesn’t need to be a DevOps expert.

Creating an Azure DevOps YAML Templates

Parameters on Azure DevOps YAML Templates

On top of the template, the first section is parameters . As our goal is to make the templates reusable, makes complete sense to have a way to change values according to which application is consuming the template. To keep it simple in this example, it was parametrized the application name.

`ash parameters:

name: applicationName type: string `

Stages on Azure DevOps YAML Templates

To have an extendible template, it must be created on the level of the stages. This example has two of them, one for build and one more for development environment. Below you can check the full template script:

Extending Azure DevOps YAML Templates

Configuring triggers on Azure DevOps YAML Templates

On top of the consumer file, in our case azure-pipelines.yml , we need to declare the triggers of the pipeline. It is mandatory to include at least one value for branch(it can be * if needed), or none . You can also set the path where your files are, and your pipeline will run only when those files change.

ash trigger: branches: include: - main - develop paths: include: - src/*

Referencing Azure DevOps YAML Templates

To extend a template, you need to provide the relative path for your template file. In this example, there is a templates directory with the file template.yml so on the consumer file, it’s necessary to provide the template path in the format ./templates/template.yml .

Image prepared by author

We also need to provide the parameter defined in our template. To this, you just need to add the parameters section right below the template, the name of the parameter, and of course, the value for it. Below there is the complete “consumer” file.

Conclusion

In this post, I introduced the basic concepts of how to extend Azure DevOps YAML Pipelines. This is easy to implement but can yield good fruits in future implementations.

In future articles, I will deep dive into this subject and show the full potential of this approach :).

Creating Azure Databricks with Bicep and Azure DevOps YAML Pipelines

Fri, 20 Aug 2021 19:45:12 +0200

Creating Azure Databricks with Bicep and Azure DevOps YAML Pipelines

Continuing the DataOps Automation series, in this post I will demonstrate how to create your Databricks workspace using Infrastructure as Code with Bicep and Azure DevOps YAML Pipelines to deploy it in Azure. Let’s check it out!

Photo by Benjamin Jopen on Unsplash

In the previous articles, you can check how to create an Azure Data Factory with git integration using Bicep and also the easiest way to create a CI/CD pipeline for Azure Data Factory

At the end of the post, you can check a complete YAML pipeline read to be used!

What is a Bicep template?

If you are not familiar with Bicep, this is a DSL for the ARM Templates, that has a cleaner syntax, better support to modules, and other great features. It also has a nice Visual Studio Code extension that helps a lot in building templates from scratch.

Nice extension for Visual Studio Code! — Image from Microsoft Docs

When you run a deployment using a bicep template, it transpile the file and generates a native ARM Template, similar to what happens between Typescript and Javascript.

If you want to learn more about it, check the official documentation here.

Creating the Infrastructure as Code for Azure Databricks

Creating a Resource Group with Azure CLI

To deploy our Databricks workspace we need to have a Resource Group created in your Azure Subscription. The easiest way to do that is through Azure CLI. To do that you need to log in with the command az login and then run the following command:

az group create -name RG-Databricks -location northeuropeReplace the parameters name and location for those that best suit your needs.

Creating Bicep templates for Azure Databricks

The Bicep template for Azure Databricks it’s quite simple and has 4 main sections:

Parameters:

Workspace Name: If you do not provide a value, it uses a uniqueString function, which ensures that it will always be the same, as this is based on the resource group id.
Location: By default, this is using the resource group location
SKU: The default value is trial, so be sure to replace it in your real-life scenario ;).

**Variables: **The template also has the variable managedResourceGroupName . This resource group will be managed by Azure Databricks to create your clusters later on.

**Resources: **Here we have only one resource that is the Databrics Workspace. This is consuming the API version 2018–04–01 .

**Output: **This section contains the variables that you need to expose. It means that they can be accessed by other processes later on in your deployment process.

Deploying Bicep with Azure DevOps YAML Pipelines

Building Bicep Template

As I said before, it is possible to “build” the Bicep template transpiling it into an ARM Template. So to ensure that our template is valid, let’s do it!

To build it, you will also use the Azure CLI. The command is also quite simple:

az bicep build –file –outdir To create an Azure DevOps YAML Pipeline, we will run the command above in an AzureCLI task:

After transpile the Bicep into ARM Template, it will deploy as a Deployment Artefact read to be consumed:

Image prepared by author

Build your Bicep is a good practice, as you can validate that there is no error in it and gather all necessary files to be deployed.

Deploying Bicep with YAML Pipelines

With the artifacts generated in the build step, now we are ready to deploy them in our environment. For that it is necessary to add one more stage into the build YAML, with the instruction to run the ARM Template:

It consumes the task AzureResourceManagerTemplateDeployment@3 that is responsible to run the ARM Template into Azure Subscription. You can have more information about this task here.

This stage represents the development stage. To deploy it in other environments, you just need to copy it and replace the values according to your environments :)

Real life example

To check these examples in more realistic situations, I have been working in a GitHub repository with examples of pipelines configured and working. You can check that in the DevOps Nights GitHub here: devopsnights/azuredevops-yaml-quickstart-templates (github.com)

Databricks YAML Pipeline

As promised below you can check a full Azure DevOps YAML Pipeline configured and working:

Conclusion

Bicep has become a very relevant tool for Azure and has a good potential to be the default tool for Infrastructure as Code in Azure. So start to be familiar with it now, will be very relevant in the future :)

I hope this post could help you, and see you in the next post!

Azure Data Factory CI-CD made simple: Building and deploying ARM templates with Azure DevOps YAML…

Fri, 13 Aug 2021 18:24:55 +0200

Azure Data Factory CI-CD made simple: Building and deploying ARM templates with Azure DevOps YAML Pipelines

The easiest way to publish/deploy Azure Data Factory artifacts

How to Create Azure Data Factory using IaC

Infrastructure as Code

There are tons of reasons to use IaC in your projects, as you can check here. One of them is that Infrastructure as Code is the easiest and fast way to implement your environment. So, as we want to keep our ADF deployment simple, why not use it :)?

In this example, I will use Bicep templates to deploy our Data Factory. If Bicep is new to you, it is basically a DSL (Domain Specific Language) to make things easier for ARM Templates users.

Bicep is has a good extension for VS Code— Image from Microsoft Docs

In this post, you can check how to create the Bicep file for Data Factory with git integration that will be used to deploy the ADF.

It will create a link between your Azure Data Factory and your git repo (it works on Azure DevOps and GitHub), so when you create a pipeline in your Data Factory, it will also be versioned into the git repo.

Git Repository

Repository Structure

The repo structure will depend on each project. One of the best practices is to keep all necessary code to deploy a project in the same repo. Due to that, I like to create a structure where I have the name of the component, and always an “src” folder underneath. In this case, we will make the src folder as “Root folder” in the git integration process.

Repository Structure — Image by author

Required files to build ARM Templates

Some files are necessary to have in our repo to generate the templates. These files need to be added to the src folder, and they will be referenced during the build stage.

In the src folder create the file package.json. It contains the metadata of the package that will be used to build the ADF Artifacts.

In the same folder also create the file publish_config.json with the content below. It will not impact the generation of the ARM Templates, but it’s necessary to run the build:

The last file is arm-template-parameters-definition.json. This contains the definitions of your ARM Parameters. I won’t go into details, as it requires a dedicated post for it. For the initial version, you can just create the content below:

After create git integrate and all necessary files this is how your repo will look like:

Repository structure for Azure Data Factory — Image by author

How to create Build YAML Pipelines for Azure Data Factory

No doubt that pipeline as code will be the future of pipeline definitions, with the capacity to be under version control and reusability.

Variables

The first configuration that is necessary is the variables. They will be used both for build and release later on.

The most important variables during the build stage are:

workingDir - This is the src directory. There must be the required files mentioned above.
dataFactoryResourceId - Fill this with the resource Id of your ADF. It’s a good idea to make it parametrizable to work in different environments

Build and Deployment Variables — Image by author

Building Data Factory

As mentioned above, we need to consume the ADFUtilities NPM package in the build process.

In the first two tasks, NodeJS is configured in the build agent. Pay attention to workingDir variable that we mentioned in the Variables section.

In the latest two tasks, we are calling the NPM package to Validate and “Build” our Data Factory and Generate the ARM Templates. In the last task “artifacts” is the relative output directory. It means that it will be the output directory to the ARM Templates.

Build tasks for Azure Data Factory — Image by author

In the next tasks, we are copying the ARM Templates from the output to the staging directory, and “building“ the bicep files into ARM Templates. These ones will be used to create the Azure Data Factory Workspace.

Build tasks for Azure Data Factory — Image by author

After running the build pipeline, you will have the artifacts that will be consumed during the deployment stage:

Azure Data Factory artifacts — Image by author

Azure Data Factory ARM Templates — Image by author

How to create Release YAML Pipelines for Azure Data Factory

To deploy Data Factory we are using the run Once strategy. It will consume the artifacts created on the build stage

Development

When the git integration is enabled in development environment, as the code is produced in the workspace, there is no need to publish in this environment. It will deploy only the environment using the Infrastructure as Code templates. It also contains a dependency for the build stage.

Development environment — Image by author

UAT and Production

In UAT we have a dependency on the development environment. In Production, the dependency is on UAT. As in these stages, we need to deploy both, infrastructure and code, we will use a preDeploy and deploy job:

preDeploy stage — Image by author

deploy stage — Image by Author

When run it will first create the Infrastructure using the Bicep files in the preDeploy Stage, and then deploy the artifacts generated on the build stage. And this is the final result:

Deployment Pipeline — Image by Author

Key Takeaways

There is more than one strategy to deploy Azure Data Factory, I have tried most of them and they work very well, but this one from my point of view is the simplest and clean way to achieve fully automated deployments.

Below you can check the complete YAML used to deploy it. You can also check other Azure DevOps YAML Templates examples in my GitHub repo: devopsnights/azuredevops-yaml-quickstart-templates (github.com)

I hope it can be useful!

DataOps Automation — Deploying Databricks notebooks with Azure DevOps YAML Pipelines

Tue, 15 Jun 2021 18:54:07 +0200

DataOps Automation — Deploying Databricks notebooks with Azure DevOps YAML Pipelines

In this post, I will show an easy way how to deploy your Databricks notebooks using Azure DevOps and YAML pipelines.

This will be the first of a series of posts, showing how to deploy code and infrastructure of Data Platform tools. I created GitHub repo to keep the examples, so if you want you can check that here: wesleycamargo/DataOps (github.com) 🙂

Image prepared by author

Project structure

The organization of this repo is based on components, so I’ll keep everything necessary to deploy some kind of component together. If you have a different structure, remember to update the yaml templates with your paths.

For databricks we have a /databricks and a /src folder, in the future it will be important to segregate from IaC code. You can have your project folders on this level, in my example, I have two notebooks inside a calculator folder`.

Project structure — Image prepared by author

Preparing artifacts

In the build stage, we will create a copy of our notebooks into a staging folder, and then publish them as build artifacts to be consumed later in the process.

We will copy all folders under /src folder, so when we deploy that into databricks workspace all folders will be created into the workspace as well.

If you run the pipeline now you already can see the artifacts and the structure:

Image prepared by author

Setting variables

In the deployment stage, we will need to consume some sensitive information like your databricks Personal Access Token. To avoid hard coding this information and to keep this example simple, let’s create some variables in the pipeline.

Image prepared by author

Deploy

To deploy we will use a special kind of job called deployment 🙂, there are some advantages to use this instead of the regular job, but I’ll do not explore them now.

In the first step, we are setting up the python version to 3.x, to that we are using a task to abstract this activity.

In the second one, we are setting app our databricks workspace. Basically, we are creating a .databrickscfg file with your token and databricks URL. To populate this file we need to consume the variables created before. So be sure that you have databricks.host and databricks.token create. We are also installing the databricks CLI to run on the next step.

And finally, in the last step we are importing the artifacts generated before using databricks CLI.

Below you can see the complete YAML template.

Hope that post can help you and see you in the next post! 😃

Az DevOps YAML Pipelines — Creating a Multi Source pipeline with GitHub Repositories

Sun, 20 Dec 2020 01:21:03 +0100

Az DevOps YAML Pipelines — Creating a Multi Source pipeline with GitHub Repositories

Sometimes should be necessary to use more than one repository in our deployment pipelines. Maybe you are deploying resources from different repositories together, or maybe you have a script repo with some reusable tools.

But when we create a YAML pipeline, by default it just checkout the repo on what our YAML is versioned, so it´s necessary to add a second repo, and below we will see how to do it =).

If you don´t know how to create a basic YAML pipeline, you can learn this here: Create your first pipeline — Azure Pipelines | Microsoft Docs

In this example, I´ll use two GitHub repositories, the first one has my App Code and the YAML pipeline, and the second one has some PowerShell scripts.

We can see the initial build YAML below:

During the build execution of this pipeline, we can see that we have an “auto checkout”, that is not required any additional configuration.

Make your deployment faster parallelizing your jobs in Azure DevOps - Classic Editor

Fri, 05 Jun 2020 22:27:53 +0200

Make your deployment faster parallelizing your jobs in Azure DevOps - Classic Editor

One of the most regular works in clients or companies that I faced, is to improve your existing CI/CD pipelines, reducing errors or the time run. In this post, I’ll show how to configure your jobs using multi-configuration.

When do I have to use this?

I’ll use as a didactic example an application with two projects: an API and a Web Site. This maybe can be a simple example, but you can find a better use for this approach in your day-to-day activities, ideally with tasks that take a long time to execute, as creating resources like Virtual Machines, Web Apps, or any other operations. The greater advantage is that if you have one job or ten, it will take just the time for one execution.

Below you can see a representation of the process. Notice that we have two Web App deployments serialized. However maybe you can have many processes, and if you have to wait for all of them, it can have a long time-consuming.

Otherwise, create a parallel activity approach, as you can see in the next image, you can save a lot of time just doing a simple configuration.

Configuring the CD pipeline

I’ll use an existing build with two outputs: an API and a WebApp. The names used in the artifacts are important, we will use this later to define our application name. Here, I’ll show you how to create an application and send it to Azure DevOps.

Create a classic CD pipeline for WebApp:

After creation, open the variables tab and create a new var named application.** **In the value enter the name of your artifacts split by a comma:

Go back to the Tasks tab and open the agent options. In item 3, notice that it has the same variable that we created before. Item 4 it’s how many parallel jobs you would like to run.

To use the multi-configuration, your WebApps names need some pattern. Here, I created a suffix and the end of the name will be the artifact name (or the split variable):

Now let’s configure the WebApp options. This is easy, just configure according to your pattern using the variable name:

Now, check if you have enough parallel jobs available in your account. The default’s it’s one parallel job for self-hosted and one Microsoft hosted agents, but if you have users with MSDN in their accounts, each one increases plus one parallel job. If you don’t have, you need to buy new parallel agents.

Running and testing :)

After running our pipeline, we can see it’s working running in two parallel agents:

After all, processes finished, we can see that’s done!

Maratona Azure DevOps -Aprendendo na prática

Thu, 21 May 2020 19:26:41 +0200

Maratona Azure DevOps -Aprendendo na prática

Quer aprender como utilizar o Azure DevOps na prática? Então assista a Maratona Azure DevOps com mais de 12 horas de vídeos GRATUITOS.

Ontem eu e a Jaqueline Ramos finalizamos a segunda edição da Maratona Azure DevOps, foram 3 vídeos com aproximadamente 2 horas de conteúdo cada onde abordamos conceitos de DevOps e como aplicar na prática utilizando a ferramenta.

A idéia da segunda edição foi de complementar o conteúdo da primeira, onde mostramos novidades como Pipelines YAML, importações de repositório e itens que não tivemos tempo de exibir na primeira.

Abaixo estão os links para os vídeos da primeira e segunda edição, vou adicionar os vídeos da segunda edição na frente pois estão mais atualizados, espero que gostem!

Segunda Edição

Primeiro episódio:

No primeiro dia da segunda edição da Maratona Azure DevOps tivemos uma abordagem mais conceitual falando sobre:

Introdução a DevOps: Cultura e Práticas relacionadas
Carreira em DevOps
Ferramentas de colaboração

Segundo episódio:

No segundo dia da segunda edição da maratona apresentamos alguns itens que não foram cobertos na primeira edição em:

Azure Boards - Como gerenciar times, criar Dashboards, alterar templates de processos
Azure Repos-Importando repositórios, utilizando Az CLI para alterações nos repositórios, criando um repositório local e enviando para o Azure DevOps, boas práticas para criação de repositórios
Azure Pipelines - Criando Pipelines YAML
Azure Artifacts - Criando um feed e enviando pacotes NuGet para o Azure Artifacts

Terceiro episódio:

No terceiro dia da maratona apresentamos:

Azure Test Plans - Conheça como você pode gerenciar seus testes com o Azure Devops através de Work Items e automações de teste
Azure DevOps e Integrações -Já utiliza Jenkins, SonarCloud, AWS ou outras ferramentas em seus projetos? Saiba como integra-las ao Azure DevOps e obter o melhor para sua empresa
Preços - Entenda como são feitas as cobranças do Azure DevOps, e COMO UTILIZAR OS RECURSOS GRATUÍTOS!

Primeira Edição

Primeiro episódio:

Azure DevOps: Introdução (Como começar, administração, custos, etc) Azure Boards: Trabalhando com WorkItens e Processo de desenvolvimento

Segundo episódio:

Utilizando Azure Repos: Controle de versão

Terceiro episódio:

Azure Pipelines: Criando seu primeiro pipeline de entrega

Quarto episódio:

Azure Test Plans: Testes integrados ao seu pipeline Azure Boards: Dashboards

Pessoas - A parte mais complexa do DevOps

Tue, 05 May 2020 19:11:47 +0200

Como tornar sua equipe mais eficiente

Por que pessoas são a parte mais complexa do DevOps?

Pessoas é** **um dos três pilares do DevOps e frequentemente é o que apresenta maior dificuldade para que o resultado seja alcançado dentro das empresas. Mas por que isso ocorre e o que não adotar de DevOps pode causar?

Equipes separadas, objetivos diferentes

Quem já trabalhou em empresas que ainda não implementam DevOps, já deve ter presenciado algumas situação em que as equipes de desenvolvimento e infraestrutura se comportam como rivais. Isso acontece pois as equipes estão divididas em Silos, e cada um desses silos possuem objetivos diferentes:

**Desenvolvimento **normalmente é cobrada por entregar software cada vez mais rápido para atender as demandas de mercado.
**Infraestrutura **tem a responsabilidade de manter a casa em ordem, com todas as aplicações estáveis, confiáveis e seguras para o cliente.

Com silos possuindo objetivos opostos, cada equipe irá trabalhar para cumprir seu objetivo, o que ajuda a explicar o sentimento de rivalidade entre as equipes.

Essa rivalidade é maléfica para o time. As pessoas em ambos os lados se sentem desmotivadas, sem o controle de seus próprios resultados, pois seu objetivo nunca pode ser cumprido sem ter que entrar em algum conflito com uma área que possui um objetivo diferente. Esse desgaste e desmotivação a longo prazo, faz os profissionais procurem ambientes mais sadios e com melhores condições, fazendo com que as empresas percam os melhores profissionais.

Além dos resultados ruins com as pessoas, a empresa também perde. Começam a aparecer os famosos “jeitinhos” para não depender da outra área, não são respeitados processos e etapas essenciais são menosprezadas. Esse tipo de comportamento pode causar falhas de comunicação, testes inadequados e culminar com maior quantidade de erros e redução na velocidade de entrega, o que ironicamente compromete o objetivo de ambas as áreas.

Não implementar novas versões mantém o ambiente estável, porém, a rapidez o que o mercado exige não é alcançada. Por outro lado, implementar com mais frequência, significa mais código sendo entregue, o que também significa que **mais comportamentos inesperados podem aparecer em produção **devido a proporção ser maior.

Criando um pipeline de CI/CD usando GitHub Actions

Sat, 02 May 2020 02:02:18 +0200

Criando um pipeline de CI/CD usando GitHub Actions

Nesse post vou demonstrar como criar uma aplicação DotNet core, versionar no GitHub, criar um workflow usando Actions e realizar deploy no Azure.

Para acompanhar esse tutorial, você vai precisar de:

Visual Studio Code - Pode ser baixado aqui
DotNet Core SDK - Pode ser baixado aqui
Uma conta no GitHub
Uma conta no Azure

Todos os comandos realizados localmente estão no arquivo abaixo, mas irei explica-los um a um no decorrer do post

Criando a aplicação

Após cumpridos os pré reqs, abra o VS Code, vá em Open folder e selecione uma pasta vazia para criarmos o projeto:

Agora vá no menu superior vá em **Terminal **-> **New Terminal **ou pressione ctrl + ‘,isso irá abrir um terminal na parte inferior da tela. Para verificar a versão do sdk instalada clique nele e digite:

dotnet –versionNo meu caso estou utilizando a versão 3.1.201, caso tenha algum problema durante a execução do tutorial e esteja utilizando uma versão diferente, utilizar essa versão pode te ajudar.

Agora para criarmos o projeto digite

dotnet new webappEsse comando irá criar a estrutura da nossa aplicação que nada mais é que um site web baseado em MVC:

Repare que serão criados alguns arquivos na pasta que selecionamos no início. Eles podem ser vistos no menu Explorer ao lado esquerdo da tela

Para verificar se tudo está ok com a aplicação, digite no terminal

dotnet runIsso irá compilar e iniciar a aplicação. Aqui também pode ser verificado em qual porta está rodando e acessar para testar

Agora que temos uma aplicação rodando, podemos seguir para a etapa de versionamento.

Para mais informações sobre comandos do dotnet core veja o conteúdo deste link https://docs.microsoft.com/pt-br/dotnet/core/tools/

Adicionando ao GitHub / controle de versão

Antes de enviar nosso código ao GitHub, primeiro precisamos versionar localmente. Antes de realizar esse versionamento, vamos criar um arquivo chamado .gitignore, onde iremos informar ao git, quais arquivos não queremos que sejam enviados, como binários por exemplo. O próprio dotnet Core possui um template pronto, onde automaticamente são adicionados os arquivos que não queremos versionar. No terminal digite:

dotnet new gitignore

Inicializando nosso repositório e adicionando todos os nossos arquivos para a área de staging.

git init

ash git add . git status

Realizando commit das alterações

git commit -m “commit inicial”

Até agora todas as operações que realizamos foram locais. Para enviarmos o código para o GitHub, primeiro precisamos criar um repositório. Acesse sua conta no GitHub e siga os passos abaixo:

Como já temos um repositório criado, copie o código da opção abaixo, cole e execute no terminal:

git remote add origin https://github.com/wesleycamargo/Pipeline-CICD.git git push -u origin master

Ao atualizar a página do repositório nosso código já estará lá

Criando Action de CI

Na tela anterior clique em Actions, o GitHub deverá identificar que o código da aplicação foi escrito em .NET Core e irá sugerir um template de workflow. Pode selecioná-lo:

Na tela seguinte será apresentado um arquivo .yml. Nesse momento vamos mante-lo assim, realizando o commit na branch master:

Será criada uma pasta .github/workflows no seu repositório, nela será adicionado um arquivo com o conteúdo abaixo:

Agora você será redirecionado para a parte de código. Clique novamente em Actions e você irá notar que foi criado um workflow e ele já foi iniciado automaticamente. Clique no evento que foi acionado e no build conforme as imagens:

Observe que é possível visualizar o log da execução do build.

Já temos um build realizando a Continuous Integration(CI) de nossa aplicação.

Adicionando Azure Web App Publish Profile ao GitHub

Vá a um Web App já existente no portal do Azure e clique em Get publish profile.

Será realizado o download de um arquivo com a extensão .PublishSettings. Copie o conteúdo dele.

No GitHub, vá às configurações para adicionar como Secret:

Nomeie como AZURE_WEBAPP_PUBLISH_PROFILE e em value adicione o conteúdo do arquivo .PublishSettings

Publicando a aplicação no Azure

Para configurar o Continuous Delivery(CD) vamos realizar algumas alterações no arquivo yml. Eu acho um pouco difícil editar pela página web, então vou realizar um pull do meu repositório local e editar no VS Code, mas você pode fazer onde for melhor para você =).

Primeiro vamos substituir o código anterior por um código mais enxuto e com uma nova função: *publish. *Vamos adicionar também uma task para realizar o upload dos artefatos gerados:

Aqui também adicionamos variáveis de ambiente para nossa aplicação. Altere os valores de WebApp_Name e DotNet_Version para os valores de acordo com seu ambiente:

env: AZURE_WEBAPP_NAME: webAppAction-wes AZURE_WEBAPP_PACKAGE_PATH: ‘.’ DOTNET_VERSION: ‘3.1.201’Com a task para realizar o upload dos artefatos, podemos notar que após executar o build podemos baixá-los:

Ao final sua aplicação estará publicada em seu WebApp:

Vou deixar aqui o link do repositório caso queiram visualizar: https://github.com/wesleycamargo/Pipeline-CICD

Valeu!

DevOps substitui os métodos Ágeis - Mitos de DevOps

Sun, 22 Mar 2020 17:29:00 +0100

DevOps substitui os métodos Ágeis - Mitos de DevOps

Tanto DevOps quanto desenvolvimento ágil se aplicam ao desenvolvimento de software visando melhorar a qualidade e velocidade de entrega de software, ou valor, para o usuário final, apesar disso, possuem maneiras de atuação diferentes.

Todo mundo que trabalha na área de TI já deve ter ouvido sobre o famoso manifesto ágil. De maneira resumida, nos início dos anos 2000, um grupo de desenvolvedores se reuniu em Utah nos Estados Unidos, cada um já adotando algum método de desenvolvimento, mas em comum todos esses métodos compartilhavam dos mesmos fundamentos.

Na minha opinião, a melhor definição de DevOps é uma cultura que combina ferramentas, pessoas e processos, para aumentar a velocidade de entrega de valor, não necessáriamente software, para o cliente. Enquanto Ágil é considerado uma metodologia de desenvolvimento onde devemos ter feedback o mais cedo possível para que possamos melhorar continuamente, portanto, poderia se enquadrar como parte do processo de DevOps.

É muito comum vermos nas empresas a combinação de ambos para que alcancem seus objetivos, pois eles se complementam. Isso pode ser feito com uma combinação de desenvolvimento ágil com outras práticas como versionamento de código, automação de build e releases, aprovações de releases automatizadas, etc (apesar de DevOps não ser apenas automação, já falei sobre isso nesse artigo). Inclusive as práticas de DevOps ajudam a fornecer esse feedback rápido para o desenvolvedor, como a utilização de validações de integração de código com builds automatizadas, por exemplo.

Mas não consigo realizar as entregas só com ágil?

Um dos princípios do manifesto ágil, é a entrega de software potencialmente “entregável”. Mas potencialmente entregável, não quer dizer implantado em produção… 🤔

A utilização de DevOps seria o complemento para que o valor gerado pelo desenvolvimento ágil chegue até o usuário final de uma maneira mais rápida e confiável, promovendo a integração das equipes, pois se as boas práticas forem seguidas, seu software já pode ser publicado em um ambiente real desde o início, evitando surpresas e retrabalhos ao final de uma iteração. Pode até mesmo ser considerado o fim da famosa frase “Na minha máquina funciona!”

DevOps é Automação - Mitos de DevOps

Fri, 20 Mar 2020 03:32:22 +0100

DevOps é Automação - Mitos de DevOps

Existem muitos benefícios de realizar as automações das etapas de nosso processo, como por exemplo, a redução do tempo de implantação uma release de 1 hora para 5 minutos. Conseguimos economizar 55 minutos de tempo de deploy!

Mas pode ser que seu processo tenha um gargalo e seu software fique 1 semana aguardando uma aprovação.

Infelizmente, esses 55 minutos economizados, se tornam praticamente irrelevantes se comparados à 1 semana aguardando aprovação. Seria mais eficiente entender o motivo de uma aprovação demorar dias ou semanas e então trabalhar para reduzir esse tempo.

No livro “DevOps Handbook”, os autores chegam a uma conclusão em que sou obrigado a concordar com eles: Uma quantidade significativa dos problemas das empresas são os mesmos, e as soluções provavelmente também são as mesmas!

Mas se as soluções para os problemas são conhecidos, por que não as utilizamos?

Nessa série de artigos baseados no livro, irei descrever alguns mitos que fazem com que essas soluções sejam ignoradas, e os problemas continuem lá, esperando para serem resolvidos.

DevOps é apenas Automação?

Quem nunca ouviu em alguma empresa ou cliente as pessoas dizerem: “Temos DevOps, fazemos todo o deploy de nosso sistemas de forma automática!” ?

É verdade que muitas práticas e padrões utilizados na cultura DevOps possuem sim processos de automação. Entre eles os mais comuns são Build, Deploy e Testes.

Entretanto, DevOps vai muito além disso! Para conseguirmos implantar o conjunto de práticas de maneira eficiente devemos considerar entre outros, os itens descritos nesse post: O que é DevOps?

Então não devo automatizar?

Sim, você deve continuar automatizando tudo que for possível dentro do seu processo: build, release, testes, ambientes, pipelines, porém não deve considerar apenas isso como DevOps.

Espero ter conseguido dar uma perspectiva um pouco diferente para que todos que tinham essa visão de que DevOps é apenas Automação, consigam explorar todo esse universo.

Até a próxima!

Referencias:

DevOps Handbook

Como criar uma conta no Azure DevOps

Mon, 27 Jan 2020 14:00:32 +0100

Como criar uma conta no Azure DevOps

Olá pessoal, irei ensinar a vocês como criar uma conta gratuita no Azure DevOps, vamos ao passo a passo:

Acesse o site https://dev.azure.com e clique no botão Start free:

Existem 3 opções principais:

Acessar como uma conta Microsoft existente (email @outlook, @hotmail, etc)
Criar uma nova conta
Acessar com uma conta do GitHub

Vamos criar uma nova conta, mas caso você já possua uma conta no Github também poderá utilizar.

Se você possuir uma conta Microsoft (outlook, hotmail, msn) poderá inserir aqui, caso não possua clique na opção para criar uma nova conta de email:

Insira um novo email que esteja disponível:

Insira sua senha:

Em região escolha Brazil:

Nesse momento sua conta será criada, aguarde alguns instantes enquanto esse processo é realizado:

Sua conta já está criada!

Agora precisamos criar um Team Project. Ele pode ser o nome da sua equipe, seu produto, ou o que fizer mais sentido para o seu projeto. Aqui podemos nomea-lo como “Projetos”

Agora seu Azure DevOps está pronto para ser utilizado!

Esse é o setup básico, como disse acima existem outras opções, mas ao final todas irão criar sua organização no Azure DevOps!