Wesley Camargo

How to Import an Existing Azure Resource into Your Terraform State with Azure Storage Backend

Thu, 15 Feb 2024 15:41:21 +0000

Have you ever for any reason didn’t had your Azure resource under Terraform and want to starting managing it by the HashCorp Tool? In this step-by-step guide, we’ll walk you through the process of importing an existing Azure resource into your Terraform state file, where your backend is configured to use an Azure Storage Account.

Preparing the Backend: Creating the Storage Account for State Management

Before we start, we need to set up an Azure Storage Account, which will be the backend for your Terraform state files. This ensures that your state is kept in a secure, centralized location, making it easier to manage, especially when working within a team.

The Azure CLI script below will create a Resource Group and a Storage Account with the container, where the state files will be created later:

1
2
3


az group create -l uksouth -n rg-tfstate
az storage account create -n sttfstateimport -g rg-tfstate
az storage container create -n tfstate --account-name sttfstateimport

Preparation of the Terraform File

Now that our Azure backend ready, lets configure the Terraform files to use it.

We will first add the azurerm backend, to do so, we will need to provide the the details from the storage account created previously, it will be required the storage account name, container name, the resource group, and the key of our workload. After that, we will create a simple resource group:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


provider "azurerm" {
 features {}
}

terraform {
 backend "azurerm" {
 container_name = "tfstate"
 key = "myworkload"
 resource_group_name = "rg-tfstate"
 storage_account_name = "sttfstateimport"
 }
}

# Create a resource group
resource "azurerm_resource_group" "example" {
 name = "rg-myresourcegroup"
 location = "UKSouth"
}

Initialize the Terraform workspace and apply the changes:

1
2


terraform init;
terraform apply;

Terraform State file

After the creation of this resource, lets check the state file hosted on our storage account. Note that we only have the resource group being managed by Terraform.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


{
 "version": 4,
 "terraform_version": "1.6.5",
 "serial": 5,
 "lineage": "f5c71b49-ac3a-e0ec-2529-b017b3c3965f",
 "outputs": {},
 "resources": [
 {
 "mode": "managed",
 "type": "azurerm_resource_group",
 "name": "example",
 "provider": "provider[\"registry.terraform.io/hashicorp/azurerm\"]",
 "instances": [
 {
 "schema_version": 0,
 "attributes": {
 "id": "/subscriptions/337ba254-3aa0-4551-ba8e-89debefaa373/resourceGroups/rg-myresourcegroup",
 "location": "uksouth",
 "managed_by": "",
 "name": "rg-myresourcegroup",
 "tags": {},
 "timeouts": null
 },
 "sensitive_attributes": [],
 "private": "xxxx"
 }
 ]
 }
 ],
 "check_results": null
}

Creation of Resource Outside Terraform Using Azure CLI

Sometimes, resources are created outside of Terraform, maybe manually or through scripts, or they might even be there before we start to adopt an Infra as Code strategy. In our case we will simulate it using Azure CLI. Create the Azure resource you want to manage with Terraform. For example, you can create a storage account, VM, or any other resource.

1

az storage account create -n sttoimport -g rg-myresourcegroup

After the resource creation, note the id of the resource. It will be needed later for the import process.

The Import Process on Terraform

Now that we have our resource and the Terraform backend is ready, we can import the existing resource into the Terraform state

Write a Terraform resource block in your configuration file that corresponds to the resource you created. Make sure the name and type match the Azure resource.

1
2
3
4
5
6
7


resource "azurerm_storage_account" "example" {
 name = "sttoimport"
 resource_group_name = azurerm_resource_group.example.name
 location = azurerm_resource_group.example.location
 account_tier = "Standard"
 account_replication_type = "LRS"
}

If you try to apply, an error message will appear, stating that the resource already existis and must be imported

The simplest way to achieve this is by adding the import block of code into your tf file. You will need to specify the id of the resource (that one we noted before) and to which resource it should be imported.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


import {
 to = azurerm_storage_account.example
 id = "/subscriptions/<subscription id>/resourceGroups/myResourceGroup/providers/Microsoft.Storage/storageAccounts/stportalcreated"
}

# # Create a storage account
resource "azurerm_storage_account" "example" {
 name = "sttoimport"
 resource_group_name = azurerm_resource_group.example.name
 location = azurerm_resource_group.example.location
 account_tier = "Standard"
 account_replication_type = "LRS"
}

After adding it, run terraform apply once again.

Terraform State file

Now we can check once again our Terraform state file. We can note that it’s much more extense, and has not only the resource group as in the first deployment, but the storage account as well.

 1
 2
 3
 4
 5
 6
 7
 8
 9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100


{
 "version": 4,
 "terraform_version": "1.6.5",
 "serial": 6,
 "lineage": "f5c71b49-ac3a-e0ec-2529-b017b3c3965f",
 "outputs": {},
 "resources": [
 {
 "mode": "managed",
 "type": "azurerm_resource_group",
 "name": "example",
 "provider": "provider[\"registry.terraform.io/hashicorp/azurerm\"]",
 "instances": [
 {
 "schema_version": 0,
 "attributes": {
 "id": "/subscriptions/337ba254-3aa0-4551-ba8e-89debefaa373/resourceGroups/rg-myresourcegroup",
 "location": "uksouth",
 "managed_by": "",
 "name": "rg-myresourcegroup",
 "tags": {},
 "timeouts": null
 },
 "sensitive_attributes": [],
 "private": "xxxx"
 }
 ]
 },
 {
 "mode": "managed",
 "type": "azurerm_storage_account",
 "name": "example",
 "provider": "provider[\"registry.terraform.io/hashicorp/azurerm\"]",
 "instances": [
 {
 "schema_version": 4,
 "attributes": {
 "access_tier": "Hot",
 "account_kind": "StorageV2",
 "account_replication_type": "LRS",
 "account_tier": "Standard",
 "allow_nested_items_to_be_public": true,
 "allowed_copy_scope": "",
 "azure_files_authentication": [],
 "blob_properties": [
 {
 "change_feed_enabled": false,
 "change_feed_retention_in_days": 0,
 "container_delete_retention_policy": [],
 "cors_rule": [],
 "default_service_version": "",
 "delete_retention_policy": [],
 "last_access_time_enabled": false,
 "restore_policy": [],
 "versioning_enabled": false
 }
 ],
 "cross_tenant_replication_enabled": true,
 "custom_domain": [],
 "customer_managed_key": [],
 "default_to_oauth_authentication": false,
 "edge_zone": "",
 "enable_https_traffic_only": true,
 "id": "/subscriptions/337ba254-3aa0-4551-ba8e-89debefaa373/resourceGroups/rg-myresourcegroup/providers/Microsoft.Storage/storageAccounts/sttoimport",
 "identity": [],
 "immutability_policy": [],
 "infrastructure_encryption_enabled": false,
 "is_hns_enabled": false,
 "large_file_share_enabled": null,
 "local_user_enabled": true,
 "location": "uksouth",
 "min_tls_version": "TLS1_2",
 "name": "sttoimport",
 "network_rules": [
 {
 "bypass": [
 "AzureServices"
 ],
 "default_action": "Allow",
 "ip_rules": [],
 "private_link_access": [],
 "virtual_network_subnet_ids": []
 }
 ],
 "nfsv3_enabled": false,
 // ... additional attributes truncated for brevity
 "tags": {},
 "timeouts": null
 },
 "sensitive_attributes": [],
 "private": "xxxx",
 "dependencies": [
 "azurerm_resource_group.example"
 ]
 }
 ]
 }
 ],
 "check_results": null
}

Conclusion

Integrating existing Azure resources into Terraform doesn’t have to be complex. By following the steps described in this guide, you can quickly and efficiently bring your Azure infrastructure under Terraform’s infrastructure-as-code management. Happy coding!

Don’t run out of credits on Azure!

Wed, 06 Dec 2023 19:01:04 +0100

Don’t run out of credits on Azure! How to shutdown Azure Virtual Machines automatically with Terraform

If you are distracted and forgetful like me, you probably already forgot an Azure Virtual Machine running without need and just figured it out when your Azure credits were gone. To avoid this, check a simple tip on how to solve this problem with Terraform.

Photo by Tristan Gassert on Unsplash

In my previous post, I have already shown how to create an Azure Virtual Machine using Terraform, now I’m adding this feature, which, for me, is very important and helps me to not spend all my Azure Credits in a forgotten VM 🙃.

What is Azure VM Auto-Shutdown?

Azure VM Auto-Shutdown is like setting a timer for your Azure VM. Auto-shutdown allows you to set a specific time so your Virtual Machine will turn off. This is a handful when you create VMs for tests, or even in development/QA environments, where you don’t need your VMs running at night when your team is not working.

Terraform resource for auto-shutdown of an Azure VM

To make it work, we will use the Terraform resource azurerm_dev_test_global_vm_shutdown_schedule. This is part of the Azure Terraform provider. The usage is quite simple, as we can see below:

The most important information required are the VM id, daily_recurrence_time, and timezone. Based on this information your VM will be shut down at the time you have defined.

Complete Terraform to create an Azure VM with auto-shutdown

To facilitate the understanding of how to integrate it in a real-life scenario, I have implemented the shutdown process in the following complete Terraform file:

Conclusion

Below it is the link to my GitHub repository where I am creating a library to have all references related to Terraform. I hope that this post despite being simple might be helpful! wesleycamargo/terraform (github.com)

👋 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

Getting Started with Azure: What are Azure Virtual Machines and how to create it using Terraform

Tue, 21 Nov 2023 18:45:11 +0100

Getting Started with Azure: What are Azure Virtual Machines and how to create it using Terraform

Azure VMs are like your own computer on the cloud. You can choose between different Operational Systems, such as Linux and Windows, and they can be used for different goals, like hosting a website for example.

Photo by imgix on Unsplash

Virtual Machines are part of a category called Infrastructure as Code, and they are still relevant in many scenarios, even with the advent of Platform as Code, where you are in control of many aspects, such as security, identity and access, high availability, and others.

What do I need to create a Virtual Machine on Azure?

To create the VM there are a few Azure resources that are necessary to be created before, as we can see in the image below:

Resources that are Pre-requisites

There are some resources that are not necessarily part of the same life cycle of your VM, and you might have already created them on your Azure environment. On the script that I am providing below, they are being created, but you might decide to use a resource that already exists.

**Resource Group: **A resource group works similarly to a folder, where you can group the resources that have something in common. It can be resources of the same type, such as VMs, or the most recommended, resources that share the same life cycle.

**Virtual Network: **In an Azure VNet, you are able to create a private space, where your resources can communicate securely. It works similarly to the network that you are connected to right now to read this post, but it sits on Azure.

Subnet: They are subdivisions of a Virtual Network, helping to keep organized and segmented by different types of resources, like Databases, Front and Backend applications.

Resources that are part of the Virtual Machine life cycle

**Disks: **Disks are used to store operating systems, applications, or data. Each VM created on Azure has at least one OS Disk, but it can have multiple.

Network Interface Card: Also known as NIC, a Network Interface Card is responsible for connecting the VM with the network that we saw earlier. Similar to disks, each VM must have at least one, but also multiple NICs are supported.

Public IP: A Public IP is the communication between the VM and the world. This resource is not mandatory, and in most cases inside a business context, it should be created very cautiously, to avoid any security risk. However, as it is a simple test and I don’t want to complicate it, we need the Public IP to be able to connect to our VM. It is connected to the Network Interface.

Terraform Script

Pre-requisites

Below is the section of Terraform that creates the pre-requisites. As I mentioned before, it is possible to use existing resources, however, you need to adapt the script to use them.

In this script, we are creating the resource group, virtual network, and subnet.

Virtual Machine

Finally, this is the script to create the VM resources. Here we create first a Public IP, the Network Interface Card, and associate the PIP on it, and a VM. Note that the Terraform VM resource already abstracts the disk internally. It’s also interesting to highlight that the VM associates the NIC created before, creating a dependency, which Terraform will identify and create in the correct order.

Complete Script

Below is the complete script, including provider, variables, and outputs:

Conclusion

👋 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

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

From Terraform to Azure Bicep: What You Need to Know about syntax

Fri, 17 Feb 2023 18:31:38 +0100

From Terraform to Azure Bicep: What You Need to Know about syntax

Photo by Botond Czapp: https://www.pexels.com/photo/birds-flying-on-blue-sky-7255793/

Hey there Terraform experts! I am confident that you know the power of infrastructure as Code in managing and provisioning IT infrastructure and have been applying it with the famous HashiCorp tool. But have you heard about Azure Bicep, the newer Microsoft IaC language for managing Azure resources? If you’re curious about the differences between Terraform and Bicep, and how Bicep can help you better manage your Azure resources, you’ve come to the right place. Let’s dive in and explore the world of Infra as Code with Azure Bicep! In this first post, I’m going to break down the basic differences between Terraform and Bicep file structures. These infrastructure-as-code tools have their own unique syntax and components, so it’s important to know what sets them apart. By the end of this post, you’ll have a solid grasp of what makes them tick.

Introducing Terraform and Bicep

Terraform and Azure Bicep are two popular Infra as Code (IaC) tools that allow developers and operations teams to manage and provision cloud infrastructure using development practices.

Terraform is a tool developed by HashiCorp that supports multiple cloud platforms, including Azure, while Azure Bicep is a newer tool developed by Microsoft specifically for managing Azure resources. Both tools have their own syntax and language for defining Infrastructure as Code and offer benefits such as consistency, scalability, and version control. However, there are also some differences between the two, such as how they handle state management and the availability of community-built providers. In the following sessions, we’ll explore the similarities and differences between Terraform and Azure Bicep, and help you decide which tool is best for your infrastructure management needs.

Language and Syntax

Terraform and Bicep has a lot in common. Both use their own domain-specific languages, with a declarative approach, support modularization, and are designed to be human-friendly(I am looking at you, ARM Templates 🙃). Terraform uses HashiCorp Configuration Language, also known as HCL, developed by HashiCorp and has several providers, supporting not only Azure, but AWS, GCP, and even VMWare. Bicep is developed by Microsoft with the intention to abstract the usage of ARM Templates and was developed specifically for Azure, which gave a great integration.

The structure of both languages is similar, within the same building blocks, with the main components being resources, inputs, and outputs, and as I said above, quite easy to read. Below we can see a comparison of the creation of an Azure Storage Account:

Image prepared by the author

Now let’s analyze the main differences:

Provider

The first and biggest difference that note is that in the Terraform example, we have a section called “provider”. As Terraform supports not only Azure but also other providers, it is required to declare the provider that we want to use.

As Bicep is designed specifically for Azure, the provider statement is not required.

Input

Another difference is that the input parameters have different reserved words. In Terraform it’s called variable, the default values are declared with a default statement and its syntax require curly brackets.

Bicep, in turn, declares the inputs by the reserved word param , the attribution of a default value can be done with the equals sign and it’s not required any brackets. Bicep also has a variable reserved world, but it’s used not for inputs, below we can see more about it.

Local variables

Local variables in Terraform have a special section called locals. All necessary variables must be declared in this section and must be accessed by the syntax local.<variable name> and can be used to create combinations and complex operations.

locals { resource_group_name = “myTerraformResourceGroup” location = “West Europe” }On Bicep, it is not necessary to have a specific session, being possible to declare anywhere in the file (although is recommended to do in the beginning to make it more readable). It also makes the syntax a little simpler than in terraform var location = ‘westeurope’

Resources

Finally something in common! For both, Terraform and Bicep, the resource is declared by the reserved word… resource! And there is more in common, in both cases, when declaring the resource you need to declare which resource is desired and you also need to create an alias to this resource, so it will be possible to access information from it, even in the case that you have several resources of the same type. The internal properties will be different depending on each resource type, but in general, you need to provide the resource name, SKU, location, and so on.

Although the concepts are quite the same, the syntax is slightly different as we can see below:

Terraform resource:

resource “azurerm_storage_account” “storage” { name = var.storage_account_name resource_group_name = local.resource_group_name location = local.location account_tier = “Standard” account_replication_type = “LRS” }Bicep resource:

resource storage 'Microsoft.Storage/storageAccounts@2022-09-01' = { kind: 'StorageV2' location: location name: storageAccountName sku: { name: 'Standard_LRS' } }n

Output

The outputs follow a similar logic as the inputs. Terraform requires curly brackets, Bicep no. In terraform, it is necessary to specify the resource type first, then the alias, and finally the property. It is also important to highlight that is not possible to assign a type to an output in Terraform.

output “storage_account_name” { value = azurerm_storage_account.storage.name }Bicep is again, slightly simple. No brackets and you can reference by the alias directly, without having to declare the resource type. In Bicep is also possible to assign a type in the output, which is useful in some cases.

output storageName string = storage.namen

Terraform storage account example

Bicep storage account example

Conclusion

In conclusion, while Terraform and Bicep share some similarities in their purpose and functionality, they have significant differences in syntax, which can affect the user experience and overall efficiency in deploying infrastructure as code. Understanding these syntax differences is crucial for developers to effectively utilize the benefits of each tool and to determine which one is the best fit for a particular project or organization.

In the upcoming posts, we will dive deeper into other differences between both tools, exploring their impact on various aspects of infrastructure deployment and management, and offering practical tips and solutions to common challenges. Stay tuned to learn more about how to optimize your infrastructure as code with Terraform and Bicep!

👋 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

Optimize Your Cloud Environment with Azure Platform Landing Zones

Sun, 12 Feb 2023 20:36:00 +0100

Optimize Your Cloud Environment with Azure Platform Landing Zones

Photo by Pascal Meier on Unsplash

What are Azure Landing Zones and why are they important?

Imagine that you are building a house, it is necessary to prepare the ground and have a solid foundation to grow your walls. Moreover, it is also necessary to prepare essential services, for instance, plumbing, heating and insulation, and electric cables in this foundation, otherwise, it will be more complicated and expensive (although possible) to do it later.

An Azure Landing Zone is the same as the house foundation, with essential services to support your platform or applications.

We can say that Azure Landing Zone is a standardized and repeatable framework for deploying and managing resources in Microsoft Azure. It provides a set of best practices and policies, that helps to improve the cloud deployment process and ensure that resources are deployed in a consistent, scalable, and secure manner.

Azure Platform Landing Zones

The set of essential services that are shared by multiple applications is also called Platform Landing Zone. These services, such as Networking and Identity management, are typically managed and centralized by dedicated teams, allowing application teams to concentrate on their core business objectives.

Azure Platform Landing Zone

Microsoft divided the Platform Landing Zones into 8 design areas. These design areas are topics that must be carefully planned to ensure the security and performance of the platform:

**Billing and Active Directory **—Billing is the process of tracking and paying for the resources used in an Azure environment. The Azure billing and cost management platform provide the ability to monitor usage and costs, set budgets and alerts, and optimize spending. Azure Active Directory is a cloud-based identity and access management service that provides centralized identity management and robust security features.
**Identity and access management **— IAM controls access to Azure resources. Azure Active Directory is the main service used for IAM and helps manage user identities, groups, and access to cloud-based apps.
Network topology and connectivity — It deals with the design and communication between virtual network resources. A good design ensures secure and efficient communication and access to the internet and external resources.
Resource organization — It involves grouping and managing resources within an Azure environment. It provides structure and scalability, making it easier to manage and control resource access. Resource groups, subscriptions, and policies to improve efficiency are used to reduce complexity, making it easy to adminstrate and ensure policy compliance in the platform.
Security — This is one of the most important design areas when planning the landing zone. It involves protecting resources with a multi-layered approach, including access control, network security, encryption, and incident response planning.
**Management — **Management in Azure Landing Zones covers processes and tools used to manage and maintain resources. A well-managed landing zone needs clear roles, a change management process, and a structured approach to resource management.
**Governance **— This is about setting the rules to keep your Azure environment organized and secure. Azure has tools like Policy and Role-Based Access Control to enforce your policies. To make things easy, make sure roles are clear and have a plan for making changes.
Platform automation and DevOps — As I am a DevOps guy for almost 10 years, I am suspicious to talk about this topic :D. It basically ensures that tools and processes make the deployment and management of applications and infrastructure easier and faster.

Conclusion

Azure Platform Landing Zones are the perfect solution for businesses looking to streamline their cloud deployment and management processes. With its centralized services, specialized teams, and powerful tools for automation and DevOps, it makes it easier than ever to bring new applications and services to market. Not to mention, the added security and governance features give peace of mind when it comes to managing resources in the cloud. So, whether you’re just starting your cloud journey or looking to optimize your existing operations, Azure Landing Zones are the way to go! So why wait? Get on board and start experiencing the benefits for yourself!

👋 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

Don’t repeat yourself! Creating Azure Bicep modules 💪

Mon, 28 Nov 2022 18:34:16 +0100

Don’t repeat yourself! Creating Azure Bicep modules 💪

Since our Infrastructure is Code now, why don’t we leverage the best software development practices? Check out this post on achieving reusability on your IaC templates using Bicep Modules!

Photo by Prateek Katyal on Unsplash

What are Azure Bicep Modules?

Bicep Modules are the application of the **Don’t Repeat Yourself **principle, where a Bicep template calls another Bicep template. As a result, this practice enables the reusability of existing code and can speed up the creation of future resources.

Imagine, for example, that you need to control how infrastructure resources are created. To accomplish this, you can implement rules in the bicep templates that, for example, restrict the size of virtual machines or the regions in which they can be created.

Since the definition has already been created and the rules, will probably remain the same in the next project, it is not necessary to create a new definition. We can create a module that allows us to save valuable time and money by reusing these definitions.

How to create an Azure Bicep Module?

If you are already familiar with Bicep Templates, creating a Bicep Module is effortless, as a module has exactly the same structure and it is not necessary to add any special configuration. It is possible, inclusive, to reuse existing templates as modules.

How to consume an Azure Bicep Module?

Declaring a Bicep Module

When working with Bicep Modules, the syntax changes compared to resources. Instead of declaring resourcethe declaration is now module**. **Additionally, it is necessary to reference the module path, which can be local or remote.

Image prepared by the author

It is also mandatory to add a symbolic name to the resource. The symbolic name can be used to recover an output from the module to be used in another part of the template.

Image prepared by the author

The property name** **is mandatory. It will become the nested template name in the final template.

Image prepared by the author

Passing parameters to Bicep modules

The parameters on modules follow the same syntax and contain the same features as regular templates. However, to send the parameters to a module it must be under the params node. It must match those declared in the module, including the validations.

Image prepared by the author

How to deploy an Azure Bicep Module?

Deployment of Bicep Modules works exactly like Bicep Templates. It is possible to use Azure CLI, Azure PowerShell, or even through Azure API.

I explain in more detail in this post how to deploy using Azure CLI. Below we can see the script used to deploy the templates and modules created above.

After running it is possible to see in the deployments of Azure Resource Group the main.bicep deployment:

Image prepared by the author

And if we click on the nested storage deployment we can observe the resource storageAccount being deployed :

Image prepared by the author

Conclusion

Reusability is one of the main advantages that we can leverage from modularization in any programming language and with Infrastructure as Code templates, it wouldn’t be different. Another benefit is that it also will ensure that your environment is more stable as your templates will be already tested by others, and most importantly, will also save implementation time.

I hope this helps you, and see you at the next one!

👋 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

Git Basic commands in a nutshell

Thu, 27 Oct 2022 14:55:13 +0200

Git Basic commands in a nutshell

Without a doubt, git is the most popular Version Control System nowadays. There is a big chance that everyone who works with IT already heard about it, or even already used git. In this post, I gathered the most common git commands in one place and a brief explanation about them.

Commit workflow — Image from Git Docs

At the end of the post, I will let all commands used with the description of them.

Prerequisites

To demonstrate in a more realistic scenario, in this post we will use a dotnet core project and, of course, the git tool. Right below, you can see all the prerequisites to follow it, and after there are links for previous posts showing how to configure git and VS Code, as well as how to install dotnet core and create a project with it.

git
Visual Studio Code
dotnet core
Windows Terminal

Git and Visual Studio Code

Git and Visual Studio Code are the main tools that we will be using in this post, so if you do not have it already configured, in this post, I describe how to set it up.

Creating a dotnet core project

To demonstrate in a more realistic scenario, we will create a simple dotnet core project. In this post, I show how to configure dotnet core on your computer, and also how to create a web app project to be used as an example.

How to configure git locally

Initializing a git repository

Initializing the git repository is the first step to start working with git. It will create the git structure, and allow you to start versioning your files. It is possible to initialize either an empty directory or a directory with files inside already. In our case, we already created the project files previously following this post.

It is possible to initialize the git repository by either the user interface or the command line, which one is better, depending on your personal preferences. Below you can see both options:

For the command line, simply type the command git init . And that’s it! Quite simple as I promised :).

What is the .git directory?

.git directory is a hidden directory that git creates to keep its files inside. You rarely need to change something in these files, but it’s worth knowing that git uses .git a directory to identify and control your repository. Due to the fact this is hidden, you need to run a special command to see it. With PowerShell, you can see with the command Get-ChildItem -Hidden

.git directory — Image prepared by Author

To verify how the files are being tracked by git, click on the git icon on the left menu. After that, it is possible to see all files under “Changes”

What are the basic git commands for local repositories

ignoring files

Before we go to the commands themselves, it is important to understand that in some cases, it is not desirable to keep certain files under source control. For example, when we work with compiled languages, it generates binary files that you don’t want to keep under version control, as they can always be generated using the code that is already versioned.

To solve this problem you need to create a .gitignore file, with instructions on which files you don’t want to keep versioned.

To create this file, as we are using a dotnet core application as an example, in the VS Code terminal, ensure that you are in the root directory of your repository and type dotnet new gitignore.

You can see that among others, the folders binand obj are listed, which is what we want in our case.

stage — Adding files to stage with git

Staging is an intermediate area where you keep your changed files before you finish the commit. It allows you to review and format them, and also makes it easy to commit your files partially.

Commit workflow — Image from Git Docs

The command git add is used to add the files to the staging area. You can add file by file specifying the name git add <your file name>, or you can add all files at once with git add .

In our project, let’s first add the gitignore that we created in the session above. It will prevent adding any undesired files that are already generated.

For this type the command git add .\.gitignore. You will notice that on VS Code the letter in front of the file name changed from U(Untracked) to A(index Added) and also it slightly changed the color. It means that this file is under the staging area.

Now that the gitignore is already there, we can add the remaining files with git add . .

Recording your changes with git commit

Finally, we will be able to create our first commit! It will record our changes in the version control. It always requires a comment, to identify what had changed in this commit. To do so, use the command git commit -m "my first commit" . Notice that all files under the source control menu disappeared, but no worries, it means that there are no more files in the staging area, and they are already “safe”.

Finding the status of your changed files

Before, we checked the files in the staging area by the user interface. But it’s also possible to use the command git status for that. Notice that is possible to visualize either the Staged and Untracked files:

Using git log to show your history

The commandgit log is used to show the commits history, and brings useful information. By default, it shows the commit hash, which helps to track in which branches, or environments the changes are, the author and date of commits, which helps to identify who made those changes, and finally the comment of the commits that shows (if used correctly🙃) the purpose of that commit.

You can also customize the results, one of my favorites is to show all commits in one line, for this you can use git log — pretty=oneline.

If you followed the first post of the version control series to set up your git environment, I also included the configuration of an alias for a log command with some formats I like to use. You can also see all details of this in this post.

Creating and moving among git branches

There are several ways to work with git and organize your branches, which is called branch strategy. In the most common it is necessary to create branches to apart your code from the stable branch.

In the DevOps community, there are polemic discussions that branching is a bad practice that avoids real continuous integration, but this is not the topic that we are approaching today.

Independent if it is a good practice or not, branches are very useful for many situations and it’s worth having it in your toolbox.

When a repository is created, it always creates a default branch, which can be called master or main depending on your preferences, and both can be used as stable branches or baselines.

It is fairly common to create branches called **features**, so it is possible to work without interfering with the stable branch.

To list the branches on your repository, simply type git branch, and it will show all local branches that you have. If you have a remote repository you can also list the remote branches with the command git branch -r.

To create a new branch use the command git branch <branch name> or git checkout -b <branch name> . Personally, I prefer the second option, as it already switches to the newlywed-created branch.

Imagine that after some commits on your feature branch for some reason you want to move back to master, so the git checkout <branch name>command will be moving from one branch to another.

All basic git commands gathered

As promised, below are all commands used in this post:

Key take aways

Git is a foundation of mostly modern development, and starting with it is quite simple. I hope that with this commands list you will help you move forward with the IT world!

How to create a dotnet core project with command line | by Wesley Camargo | Oct, 2022 | Medium

How to setup your environment with git and VS Code with choco | by Wesley Camargo | Oct, 2022

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

🚀Join FAUN & get similar stories in your inbox each week

How to create a dotnet core project with command line

Wed, 26 Oct 2022 18:21:02 +0200

How to create a dotnet core project with command line

In this post, we will see how to simply create a dotnet core application using the command line. For that, we will use Windows Terminal with PowerShell, but it is possible to use any terminal for it :)

Photo by Vipul Jha on Unsplash

Installing dotnet core with command line

Install dotnet core with the command line is quite simple. For that, we will use Winget with the command below:

Creating dotnet project in Windows Terminal

For this post, we will use Windows Terminal, but you can use any terminal that you want.

Open the terminal in the directory that you want to create your project and type the command dotnet new webapp -n demo . It will generate a directory called “**demo” **within the project structure.

Enter into the directory created and type code . . This command will open the Visual Studio Code in your project directory:

In the VS Code is possible to see the project structure, as we can see below:

How to build and run a dotnet core project locally

Now let’s build our dotnet project to ensure everything is working properly. The easiest way to do that is using the integrated terminal in VS Code.

To open the terminal type ctrl + `` or go to **View > Terminal. **In the terminal that will appear at the bottom of your VS Code, type the command dotnet build` . If everything goes well you should see the **Build succeeded **message.

We can now run our web app with the command dotnet run . It will start the web app locally in some ports. You can copy one of them and open it on your browser:

Conclusion

In further posts, we will see more about DevOps practices, and having a real application to start with is crucial to understand all the steps that will be applied in a real-life scenario.

I hope this post could be useful and see you in the next one!

How to create commits with different users in git

Wed, 19 Oct 2022 23:12:09 +0200

How to create commits with different users in git

In my previous post, I showed among other stuff how to configure your git credentials. But in case you need to use different users in different projects or repositories, you need to be sure that your commits are using the correct credentials. Check on this post how to configure it properly and stop messing up your repos ;)

Photo by Yancy Min on Unsplash

I know a lot of people that already made a commit using the wrong credentials in either work or personal repos. Having to remember to configure this in every new repository is not the best way to do that.

For this, we can use Conditional Includes when creating our config file. This is a bit more complex than just setting the user and email, but it will help you to avoid a lot of work, in case you need to rewrite your commit history later :).

Understanding the git configuration

The git configuration is used to introduce customized behaviors on git and it has three different scopes of settings:

**System **— In this scope, the settings are applied to all users and all repositories. To edit this scope use the parameter --system . To verify which configurations are in the system scope, type the command git config --system -l
**Global **— This is the user scope, where it is possible to customize settings using the parameter --global , and it is applied to all repositories of that user. The global configuration file sits in the user directory on your computer.
Local— Each repository can also have its own customized settings. It is possible to find the configuration file in the git directory inside each repository ./.git/config , or it is also possible to check with the parameter--local .

The lower the scope, the higher the priority, so it means that the local scope overrides the global scope, and the global overrides the system scope. With that said, the precedence is in the following order: System> **Global **> Local

It is possible to trace back from where the configuration is coming from: git config -l --show-origin

Different scopes of configuration — Image by author

In our case, we will play around with the user’s configurations. These configurations are stored in a file .gitconfig that sits in your user directory, as mentioned above. To easily access it, you can type ~/.gitconfig in your terminal and you will be able to see something similar to this:

Creating the conditional includes in gitconfig

For each user we want to use, it is necessary to create a separate folder, where the repositories will sit. This is because we will use the directory that git specifies in its configuration to identify where we are. In my example, I will configure my global email, which will be used for all repositories, except those under the folder c:\repos\work .

With our work repositories under the correct folder, we need to create a specific configuration file for that “profile”. You can type the command echo [user] > ~/work.gitconfigto create it under your user directory. After creation, populate with needed information for the profile, as per below:

After creating the work.gitconfig file, in your main file (.gitconfig), include the [includeIf] session. The command gitdir/i will return the directory of your repository, and if it matches the directory that you specified, it will load the work.gitconfig .

Concluding…

This configuration is quite simple, but can be very helpful if you work in many projects simultaneously . I hope it can help somehow 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 & get similar stories in your inbox each week

How to setup your environment with git and VS Code with choco

Mon, 10 Oct 2022 15:10:04 +0200

How to setup your environment with git and VS Code with choco

Configuring your git environment is something very important to begin using version control. In this post, I will show you, step by step, how to install and configure git correctly and also how to use Visual Studio Code as a default editor, And at the end of the post, there are the full scripts to help you set up your environment, **with a bonus **in it ;).

Photo by Yancy Min on Unsplash

How to install git and Visual Studio Code with PowerShell and Choco

How to install Chocolatey with PowerShell

Before we proceed with git and VSCode, first we need to install the Chocolatey. Chocolatey, or simply Choco, is a package installer designed for work with PowerShell.

The easiest way to install choco is by running a PowerShell script in your terminal. Below I have prepared a script that calls the official Choco script on its site:

How to install git on Windows using choco

After installing Choco, we will be able to install the git package available there. To install, the command is very straightforward as we can see below (might be necessary to run the command with administrative privileges):

After the installation, check if git was correctly installed with the command git -v :

If you receive an error saying that git is not installed, close and reopen your terminal, it will reload the environment variables with the correct git path.

How to install Visual Studio Code with choco and PowerShell

As well we saw to install git, the command to install VSCode with choco and PowerShell is also very simple:

To check the installation, use the command code -v . Again, in case of any problem, close and reopen your terminal.

How to setup git credentials

How to setup git username and email

To associate your identity with your commits, it is necessary to define your git user name and email. You can configure it in different scopes, below we can see how to configure it globally:

How to setup Visual Studio Code as the default git editor

The default editor for git is nano. Personally, I prefer VS Code, as it has several extensions that can improve productivity. In the script below, we are setting up the VSCode as the default tool for the command diff and merge and also as the default editor:

How to install and configure Git and VS Code with PowerShell Script

Installation

To install all necessary tools, you can simply run the script below. Might be necessary to have administrator permissions for that. In the first 6 lines, the script installs choco, and then uses choco to install git and vscode:

Configuration

After installing the tools, you may need to reload your terminal, as I said above, so to make it easier I created two different scripts 😉. As a Bonus, I also added an alias to a command git lg, which is an alias for git log , but using prettier options. You can check more about it on this post Creating a pretty git log:

Conclusion

Source control is the basis of any DevOps process, and git is currently the most used tool for it. Using the right configuration together with VS Code will help to start this journey!

References

Git — Installing Git (git-scm.com)

Chocolatey Software Docs | Chocolatey — Software Management for Windows

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

🚀Join FAUN & 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

Como funcionam os Loops — Developer BR — Corujinhas

Wed, 27 Jul 2022 23:48:29 +0200

Como funcionam os Loops — Developers BR — Corujinhas

Loops

O que é um loop ou laço?

Um loop é uma maneira de executar um trecho código repetidas vezes. É composto de uma condição e o código que será executado.

O loop é representado por um circuito fechado, e enquanto a condição não for satisfeita se repete infinitamente.

Condições de um loop

As condições são usadas para verificar quantas vezes o trecho de código será repetido. Antes de cada execução (ou depois, dependendo do tipo da estrutura de repetição usada), a condição é verificada e se continuar verdadeira o código é executado. Os tipo de condições podem ser:

Verdadeiro ou Falso
Um número específico de vezes
O número de elementos em uma coleção

Código

Praticamente qualquer tipo de código pode ser executado em um loop, não há restrições! Em alguns casos, certos tipos de variáveis são usadas para ajudar a controlar o que está acontecendo durante as repetições. Essa variável é chamada de contador.

Quando usar um loop

Usamos loops quando precisamos fazer a mesma coisa várias vezes. Vamos a um exemplo:

Imagine que estamos criando um sistema para uma cafeteria. Os requisitos para esse sistema são:

Para cada novo café pedido escrever na tela o número do pedido que está sendo executado
Ao final exibir a quantidade total de cafés preparados

Para simplificar, vamos imaginar que temos 3 pedidos de café e precisamos executá-los. Como seria esse código?

int cafesPreparados = 0;

ash // Preparando o café cafesPreparados++; Console.WriteLine($“Preparando o 1° café”);

ash cafesPreparados++; Console.WriteLine($“Preparando o 2° café”);

ash cafesPreparados++; Console.WriteLine($“Preparando o 3° café”);

ash Console.WriteLine($“Total de devs felizes: {cafesPreparados}”); Não parece tão complicado, certo? Realmente, se tivermos poucos pedidos não é uma tarefa difícil, mas temos dois problemas:

No caso de apenas 3 pedidos, foram apenas mais 6 linhas de código, mas e se fossem 100? Ou 1000? Teremos um programador bem entediado repetindo esse código tantas vezes…
Além do problema acima, de termos tarefas repetitivas, nós adicionamos dentro do código cada pedido feito - O que impede de recebermos pedidos dinamicamente e na pratica inviabiliza a aplicação.

Mas imagine que agora nossa cafeteria aceita pedidos online, e recebeu 10000 pedidos. Como fazer isso?

É nessa situação que os loops vão te ajudar!

Tipos de loops

While

É o tipo mais básico de loop. No while, a condição é verificada antes da execução, e se for verdadeira o código é executado. Normalmente é usado para comparações de verdadeiro e falso mas com um pouco mais de trabalho, ele consegue substituir algumas das outras estruturas de repetição, como for e forEach.

As principais características do while são:

Enquanto uma condição for verdadeira(ou falsa), continue repetindo.
Executa o trecho de código uma vez, volta ao inicio e verifica se a condição continua verdadeira e executa novamente.
Atenção! Isso pode acontecer para sempre, desde que a condição continue verdadeira! Isso é chamado de loop infinito e na maioria dos casos não é desejado.

ash Console.WriteLine("Quantos devs precisam de café?"); *int* devs = Convert.ToInt32(Console.ReadLine());

ash *int* cafesPreparados = 0;

ash while (cafesPreparados < devs) { cafesPreparados++; Console.WriteLine($"Preparando o {cafesPreparados}° café"); }

ash Console.WriteLine($"Total de devs felizes: {cafesPreparados}");

Do While

Para do while, acontece o oposto, o código é executado e apenas após a condição é verificada. Isso pode ser útil em casos onde pelo menos uma execução é sempre necessária.

ash Console.WriteLine("Quantos devs precisam de café?"); *int* devs = Convert.ToInt32(Console.ReadLine());

ash *int* cafesPreparados = 0;

ash do { cafesPreparados++; Console.WriteLine($"Preparando o {cafesPreparados}° café"); } while (cafesPreparados < devs);

ash if (cafesPreparados > devs) { Console.WriteLine($"Oh não! O café está esfriando e nenhum dev está por perto!"); } else { Console.WriteLine($"Total de devs felizes: {cafesPreparados}"); }

For

O for funciona da mesma maneira que o while. É recomendado seu uso para casos em que a quantidade de vezes que a repetição deve acontecer é conhecida. Para declarar um for é necessária uma variável, chamada index ou i e são necessárias 3 declarações separadas por ponto e vírgula(;):

Inicializar: Declaramos o valor inicial do índice
Condição: Adicionamos a comparação que será usada para parar o loop
Iterar: Incrementamos o índice, normalmente com ++

ash Console.WriteLine("Quantos devs precisam de café?"); *int* devs = Convert.ToInt32(Console.ReadLine());

ash *int* cafesPreparados = 0;

ash for (*int* i = 0; i < devs; i++) { Console.WriteLine($"Preparando o {i}° café"); cafesPreparados = i; }

ash Console.WriteLine($"Total de devs felizes: {cafesPreparados}");

Foreach

O foreach é recomendado quando trabalhamos com coleções ou listas. Sua tradução é “para cada”, o que significa o trecho de código será repetido uma vez para cada elemento da lista.

ash var developers = new List<*string*>(); *string* maisdevs = "s";

ash do { Console.WriteLine("Digite o nome do dev:"); developers.Add(Console.ReadLine() as *string* ?? string.Empty);

ash Console.WriteLine("Mais algum dev precisa de café? [S/N]"); maisdevs = Console.ReadLine() as *string* ?? string.Empty; } while (maisdevs.ToLower().Equals("s"));

ash foreach (var dev in developers) { Console.WriteLine($"Preparando café para o dev {dev}"); }

ash Console.WriteLine($"Total de devs felizes: {developers.Count}");

GitHub do Corujinhas

Para os exemplos completos, veja o repositório do corujinhas no GitHub! Developers-BR/corujinhas (github.com)

Creating Infrastructure as Code for Azure with Azure Bicep step by step

Wed, 23 Mar 2022 10:54:57 +0100

Creating Infrastructure as Code for Azure with Azure Bicep step by step

Photo by Arisa Chattasa on Unsplash

One of the natural steps towards DevOps and Cloud Adoption is to create your Infrastructure using Code. For Azure, the most convenient language for this is Azure Bicep which abstracts several aspects of this complex process, and supports more resources available in Azure than any other tool, making it one of the most powerful Infrastructure as Code tools for Azure.

What is Azure Bicep?

According to Microsoft Documentation, this is the definition of Bicep:

Bicep is a domain-specific language (DSL) that uses declarative syntax to deploy Azure resources. In a Bicep file, you define the infrastructure you want to deploy to Azure, and then use that file throughout the development lifecycle to repeatedly deploy your infrastructure.

In summary, this is an abstraction over ARM templates which simplifies A LOT the development of Infrastructure as Code. Its syntax is much simpler and less verbose than ARM but still has all its capabilities.

As bicep is a DSL, we can consider ARM as an Intermediate Language and we can “build” bicep into ARM to perform our deployments. A curiosity is that the name bicep is a play on words for ARM (Azure Resource Manager) 😄.

How to create an Azure Resource Group with Azure Bicep?

Usually, one of the firsts resources on Azure that we need to create is a Resource Group, as it will group all other resources, and make it easier to administrate.

Create an Azure Resource Group using Azure Bicep it is quite simple, you need just the name of the resource group and the location that it will be created. Additionally, it is necessary to define the *targeScope *as a subscription, it will be explained in more detail below.

It is possible to deploy it in different ways, using Azure PowerShell, Azure CLI, or even Azure API’s. In this example, we will use Azure CLI to execute the deployment.

How to execute an Azure Resource Group deployment with Azure Bicep and Azure CLI?

On the latest versions of Azure CLI, there are different commands to run deployments against different scopes on Azure. To create Azure Resource Groups, it is necessary to use the *subscription *scope, which was also defined on the bicep template above.

The command used is az deployment sub create :

After running the script, we can check the resource group with the command az group show --name rg-bicepdemo :

Image by author

How to create an Azure Storage Account with Azure Bicep and Azure CLI?

When we will create a “common” resource, like Storage Account, Resource Group scope must be used. This is the default behavior of bicep, so it is not necessary to specify like it was for Resource Group creation.

To create resources on Resource Group scope, the Azure CLI command used must be az deployment group create :

To check the Storage Account creation run the command az storage account show --name stbicepdemo

Image by author

As they are in different scopes, it is not possible to run both bicep files with one command, however, I prepared a PowerShell script to run them in sequence:

Conclusion

Azure Bicep is one of the most promising Infra as Code tools for Azure, and it is quite simple to create new templates for it. Its syntax is very simple and easy to learn, so why not give it a chance? :)

See you in the next post! [

](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 👇

It’s time to tidy up your code: How to use Visual Studio Code Autoformat

Wed, 16 Mar 2022 12:25:13 +0100

It’s time to tidy up your code: How to use Visual Studio Code Autoformat

Photo by Jozsef Hocza on Unsplash

If you are like me and like to have consistency in formatting your code, this is definitely a must to have configuration.

By default, you can use VS code formatters with the shortcut Alt+Shift+F but, you can also configure it to format every time you save your file, like this:

How to enable autoformat on Visual Studio Code

There are two options to enable autoformat by UI and editing settings.json file, let’s check both:

How to edit autoformat option on VS Code User Interface

Open the menu File->Preferences->Settings and under Text Editor look for Formating and enable the option Format On Save choosing which option is better on Format On Save Mode .

If you’re using version control, you can choose to format changes only, this is particularly useful if you’re working on legacy code and don’t want to change a large file at once. For this option choose modificationsIfAvailable .

How to edit autoformat option on VS Code settings.json

To find settings.json file, open your Visual Studio Code and press F1:

Now type settings.json , open the file and add the section:

For the configurationFormat On Save Mode you can pick of the of the options below:

file
modifications
modificationsIfAvailable

This is how your file should look like:

This configuration applies to most part of the supported languages, like PowerShell, JSON, C#, and others.

How to autoformat Terraform files on Visual Studio Code

Although the configuration above works for most languages if you are using terraform you need additional configurations. The plugin also doesn’t have a UI for it, so we need to add the configuration manually in the file settings.json.

To do it, open again the settings.json file and add the following sections:

Pay attention that you must add one section for Terraform, and one more for terraform-vars.

This is the final file:

Conclusion

Autoformatting is an easy and helpful option that will for sure help your team to have consistency and keep your codebase tidy and clean.

See you in the next post! [

](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 👇

First steps with Azure: Creating an Azure Resource Group with Azure CLI

Mon, 07 Mar 2022 18:25:56 +0100

First steps with Azure: Creating an Azure Resource Group with Azure CLI

An Azure Resource Group is a container that holds related resources for an Azure solution. This is an important resource in Azure and in this post, I will continue the series of Basic commands for Azure CLI and show how it is possible to create Azure Resource Groups using Azure CLI.

Photo by Simon Infanger on Unsplash

What is Az CLI?

Az CLI or Azure CLI is a command line interface with Azure. It can be used in any command line prompt, including PowerShell and Bash, and it allows the creation of resources and resource groups, executing actions, and much more possibilities. In the previous post, I showed the basic commands to connect and configure your Azure Subscription using Azure CLI, if you don’t know how to configure your Azure CLI local environment you can check it here.

What is an Azure Resource Group

According to Microsoft documentation, this is the definition of an Azure Resource Group:

A resource group is a container that holds related resources for an Azure solution. The resource group can include all the resources for the solution, or only those resources that you want to manage as a group. You decide how you want to allocate resources to resource groups based on what makes the most sense for your organization. Generally, add resources that share the same lifecycle to the same resource group so you can easily deploy, update, and delete them as a group.

In practice, we can consider it as a “Directory” on Azure where you can group your resources. There are many ways to organize it, the most common is to make them small with resources of the same context.

For more information, you can check the official documentation here.

Az CLI commands for Azure Resource Group

Azure Resource Group - Summary of commands

Below there is a summary of all commands used in this tutorial. You can copy it and replace the values between <> to your own values :)

How to use Az CLI Help?

It is also possible to check all commands related to resource groups with the command az --help . For more details about how to use the help check this post where I also show how to login into Azure Subscription with Azure CLI.

az group help — Image by author

How to list existing Azure Resource Groups with Az CLI

The command used to list Azure Resource Groups is az group list . It will return a JSON by default. To have a more human understandable output you can add --output tablein front of the command or any other output of your choice. The final command would beaz group list --output table .

az group list — Image by author

How to create an Azure Resource Group with Az CLI

To create a new Azure Resource Group, it is necessary to provide two required information:

Location: The Azure Region where your resource group will be created.
**Name: **The name of your Resource Group

The final command is az group create --location <location of your resource group> --name <name of your resource group> . Replace the content between <> with your own values .

az group create — Image by author

To check additional options use the command az group --help .

After creation, run again the command az group list --output tableto check if the resource group is shown.

az group list — Image by author

How to show details of an Azure Resource Group with Az CLI

To check the details of a specific Resource Group, you can run the command az group show --name <your resource group name> . This command returns basically the same information after the creation command.

az group show — Image by author

How to delete an Azure Resource Group with Az CLI

The delete command will prompt if you are sure about executing the delete operation. This is because all resources created under this resource group will also be deleted, so run this command only when you want to delete them as well.

After the conclusion of the command, after running the list command the created resource group is not listed anymore.

Conclusion

The Resource Groups are an important part of Azure and automating its creation is a fundamental part of a DevOps process.

See you in the next post! [

](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 👇

The entry gate to Azure: Configuring your Azure subscription with Azure CLI

Fri, 25 Feb 2022 16:51:35 +0100

The entry gate to Azure: Configuring your Azure subscription with Azure CLI

Azure CLI is a command line interface with Azure. It can be used in any command line prompt, including PowerShell and Bash, and it allows the creation of resources and resource groups, executing actions like an Azure Data Factory pipeline, and much more possibilities. In this post, I will show the basic commands to connect and configure your Azure Subscription.

Photo by Jan Tinneberg on Unsplash

How to set an Azure Subscription with Azure CLI

Below is a summary of all commands used

Now let’s see the details of execution for each command.

How to know which commands to use in Azure CLI

At least in the beginning until you get familiar with the commands a very useful tip is to make use of the help command. It’s quite simple and you just need to add --help or -h after the command. The most basic would be to run it after az like az --help . It will show all subgroups and commands available for the tool.

Image by author

The easiest way to login into Azure is using the interactive mode. It will open a new tab on your browser with the authentication page.

To do it run the command az login and choose your account:

Image by author

By default, after choosing your account it will prompt a list of available subscriptions on that account. These subscriptions can also be listed with the command az account list, described below.

How to set a subscription with Azure CLI

First, we need to see which subscriptions are available. To do it run the command az account list , this command will display all subscriptions available in your logged accounts.

Image by author

Once you have your subscriptions id, you can connect to it through the command az account set --subscription . After this command, you can confirm if the subscription was settled by running the command az account show

Ìmage by author

Conclusion

Although the commands are simple, they are very important, as they are an entry gate to interact with Azure. [

](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 👇

Criando Azure Resource Group com Azure CLI

Thu, 24 Feb 2022 18:26:54 +0100

Criando Azure Resource Group com Azure CLI

O Azure CLI é uma interface de linha de comando para o Azure. Ele pode ser usado com PowerShell ou em bash, com ele é possível criar recursos, resource groups, executar ações no Azure entre outras coisas. Aqui vou mostrar os comandos básicos para conectar ao Azure utilizando o Azure CLI e como criar um resource group.

Photo by Milad Fakurian on Unsplash

No vídeo abaixo é possível acompanhar todo o processe de conexão ao Azure e criação do Resource Group usando Azure CLI. Após o vídeo estão os comandos utilizados e um breve resumo sobre seu uso.

Como conectar ao Azure com Azure CLI

Azure CLI - comandos para Account

Abaixo estão todos os comandos utilizados para realizar login e configurar a Azure Subscription para ser utilizada

Agora vamos ver os detalhes de execuçao dos comandos:

az -h — Lista os comandos disponíveis no Azure CLI

az login- Abre a página de login no browser para selecionar a conta que será conectada

az account list - Lista as subscription disponíveis az account set -subscription - Seleciona a subscription que será usada az account show - Exibe as informações da subscription atual

Como criar um Azure Resource Group com Azure CLI

Azure CLI — comandos para Resource Group

az group -h - Lista os comandos disponíveis para Resource Groups az group create -h - Lista os argumentos necessários para criar um Resource Group

az group create --location -–name - Cria um Resource Group

az group list --output table - Lista Resource Groups da subscription em formato de tabela

az group delete --name- Apaga o Resource Group

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 :).

How to suppress warning and error messages in Azure CLI

Mon, 20 Dec 2021 09:02:01 +0100

How to suppress warning and error messages in Azure CLI

In Azure CLI some commands can return errors and warning messages, which can cause troubles on your script, so check out how to suppress it

Photo by Muhammad Daudy on Unsplash

How to suppress warnings on Azure CLI

Command group is in preview and under development

In some cases the CLI used can be under development and show the message: Command group is in preview and under development. Reference and support levels: [https://aka.ms/CLI_refstatus](https://aka.ms/CLI_refstatus)

At the moment that I am writing this post, the az devops CLI variable-group for example is always returning the message above, which have been causing troubles and breaking my pester tests :)

Photo prepared by author

Quiet mode on Azure CLI

For Azure CLI, the simplest way to make the commands “quiet” is by adding the global parameter --only-show-errors in your command. **It will suppress only the warnings **and keep the message in case you have any errors during the execution.

So in our example for az pipelines variable-group our command will be like this:

ash az pipelines variable-group list --org $organization -p $project --only-show-errors

How to suppress errors on Azure CLI

In some cases, you may need to also suppress the errors during your script execution and there is one more option for it. I would recommend this approach only if you really do not care if something went wrong during your script execution.

Redirecting the console output STDERR

A common scenario to redirect streams is when the symbol > is used to write the output of the command in a file. It redirects the standard output - STDOUT - to the file added as a parameter.

In the situation that is necessary to suppress the errors, we need to redirect the output of the error stream — STDERR.

To do it you simply need to add 2>nul after the CLI command, which means that the second stream (STDERR) will be redirected to null .

So in our example for az pipelines variable-group the command will be:

ash az pipelines variable-group list --org $organization -p $project 2>nul

Conclusion

Although this topic looks simple, sometimes it’s not so easy to find this information in the documentation, especially regarding the error suppressing topic, and also the comparison of both approaches is not documented.

I grouped both, how to suppress warnings and errors in one place, so would be to choose which option suits better in each scenario.

References

Redirecting error from Command Prompt — Visual C++ | Microsoft Docs

https://github.com/Azure/azure-cli/issues/13384

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 — Creating Azure Data Factory with git integration using Bicep

Sun, 25 Jul 2021 00:48:52 +0200

DataOps Automation — Creating Azure Data Factory with git integration using Bicep

An important feature available in Azure Data Factory is the git integration, which allows us to keep Azure Data Factory artifacts under Source Control. This is a mandatory step to achieve Continuous Integration and Delivery later on, so why not configure this using Infrastructure as Code with Bicep in a fully automated way?

Image prepared by author

In the official Microsoft documentation there is a good topic explaining how to integrate Azure Data Factory with git, but through the Azure Portal. In this post, I will explain how to do that using Bicep, the new IaC language for Azure, to make it possible to include this step into your CI/CD process, and also how to deploy only on needed environments.

Azure Data Factory Git integration

Okay, but why do I need to use git on my ADF? To explain this, I’ll list some advantages that the git integration offers, taken from Microsoft’s documentation:

Source control

As your data factory workloads become crucial, you would want to integrate your factory with Git to leverage several source control benefits like the following:

Ability to track/audit changes.
Ability to revert changes that introduced bugs.

Partial saves

When authoring against the data factory service, you can’t save changes as a draft and all publish must pass data factory validation. Whether your pipelines are not finished or you simply don’t want to lose changes if your computer crashes, git integration allows for incremental changes of data factory resources regardless of what state they are in. Configuring a git repository allows you to save changes, letting you only publish when you have tested your changes to your satisfaction.

Collaboration and control

If you have multiple team members contributing to the same factory, you may want to let your teammates collaborate with each other via a code review process. You can also set up your factory such that not every contributor has equal permissions. Some team members may only be allowed to make changes via Git and only certain people in the team are allowed to publish the changes to the factory.

Better CI/CD

If you are deploying to multiple environments with a continuous delivery process, git integration makes certain actions easier. Some of these actions include:

Configure your release pipeline to trigger automatically as soon as there are any changes made to your ‘dev’ factory.
Customize the properties in your factory that are available as parameters in the Resource Manager template. It can be useful to keep only the required set of properties as parameters and have everything else hardcoded.

Better Performance

An average factory with git integration loads 10 times faster than one authoring against the data factory service. This performance improvement is because resources are downloaded via Git.

Git Integration is only for Development Environment

There are two flows recommended by Microsoft to perform CI/CD on ADF, (you can check it on this post), in both cases the development happens in the Development Data Factory workspace only, and the artifacts are promoted through CI/CD deployments. It means that we should not create this integration for non-dev environments like UAT or Production. I will also cover how to identify the environment and create the integration only for your development environment :)

Creating Bicep templates for Azure Data Factory step by step

To keep the explanation simple, I’ll show each stage of the bicep file. Each stage is a deployable file that you can execute individually with the command

*az deployment group create -f .bicep -g *In the end, we will have the complete file ready to use.

Creating Data Factory Workspace

In the first stage, we are creating only the workspace with the most basic configurations. You can see that for the location we are using the location of the Resource Group where we are executing this deployment.

Linking GitHub with Azure Data Factory

In this stage we achieve the first goal of this post: create the **git integration. **I include the parameters necessary to connect with a GitHub repo, and then a section into “properties”. Now lets check the parameters:

**accountName - **This is your GitHub/Azure DevOps account name.
**repositoryName **- Name of your repository, pay attention that you don’t need your account name at the beginning.
**collaborationBranc **- The branch that will be used to integrate your feature branches. It will depend on your branch stratety. For git flow, it should be developed branch, for GitHub Flow, master/main.
**rootFolder **- The folder in your repo where the databricks artifacts will be versioned.
projectName - This parameter is only used for Azure DevOps. It’s the Team Project name of your repo.
**type **- This parameter defines if your repo is hosted on GitHub or Azure DevOps. For GitHub, the value must be:

FactoryGitHubConfigurationFor Azure Devops the value is:

ash FactoryVSTSConfiguration

Image prepared by author

Checking the environments

As was explained above, we must create git integration in the development environment only. If you are using only GitHub or only Azure DevOps, this stage should be enough for your scenario. To check that, we need the following steps:

An environment parameter.
Extract the content of repoConfiguration to an external variable.
Use a ternary if to check if the environment provided is development. If it is, then use the variable, if not, use an empty group.

Image prepared by author

The bicep file of this stage:

Linking GitHub or Azure DevOps to Azure Data Factory

In case that in your scenario you have both Azure DevOps and GitHub, you can prepare your template to support that. This template is more flexible and can be used in more situations. Let’s check the differences from the previous one:

Included a “User Friendly” parameter to indicate the type of the repo.
Check the type parameter and create a variable with the expected value.
Create two configurations, one for GitHub and one for Azure DevOps.
Include another ternary if nested into the first one

Image prepared by author

Below you can check the final bicep template:

Real life example

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

In this post, I am showing how to consume this Bicep Template into an Azure DevOps Pipeline.

I hope this post can help you to create your ADF in a more automated way, and see you in the next post!

References

Source control — Azure Data Factory | Microsoft Docs

Factories — Configure Factory Repo — REST API (Azure Data Factory) | Microsoft Docs

Microsoft.DataFactory/factories 2018–06–01 — ARM template reference | Microsoft Docs

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! 😃

DataOps Automation — Accessing Databricks API with AAD Service Principal Name

Sat, 29 May 2021 16:24:43 +0200

DataOps Automation — Accessing Databricks API with AAD Service Principal Name

Databricks is an Apache Spark tool for data engineering used to process and transform large amounts of data and explore running machine learning models.

In this post I’ll show how to call databricks API’s, an important resource to automate the deployment and resources creation.

Preparing Tokens

Yes, you read it right tokens in the plural, we need more than one token to perform authentication.

Actually, if your SPN is a user in your databricks workspace only the AAD token should be enough, but I believe that in most situations if you want to automate from scratch your workspace it will not be the case.

Creating AAD token

To create an AAD token it´s necessary the tenant Id of your subscription, an SPN Id, and SPN secret. If you don’t know how to create a Service Principal Name check it out here Create an Azure AD app & service principal in the portal — Microsoft identity platform | Microsoft Docs

For this, I have created the function below, as we will use it more than once.

Preparing HTTP header

As I mentioned before, we need two AAD Tokens if our SPN is not added as a user into databricks.

The first token is a databricks token. To create that we need to provide the databricks resource id (2ff814a6–3304–4ab8–85cb-cd0e6f879c1d).

If your SPN is a user in your databricks workspace, only this token should be enough.

The second one is the management endpoint token you also need to provide the resource id, in this case, it should be “https://management.core.windows.net/”. Additionally, your SPN must have Contributor or Owner permissions on your databricks.

Creating the databricks Personal Access Token

With our header prepared, you just need to call the databricks API, consuming the methods that you need.

Complete Script

Below you can find the complete script, including the auxiliar functions :)

I hope it can help you, and see you in next post!

Creating a pretty git log

Sat, 01 May 2021 12:33:52 +0200

Creating a pretty git log

Do you know git lg command? Git log command is very helpful, but sometimes, it can be a bit tricky to have a good view of your history tree. I’ll show with simple commands how to improve that and create your customized log message :).

The default git log command brings a lot of useful information, as we can see in the picture below. But when you need to know which branch your commit was originally created, it didn’t give you a good tree view of that.

Azure Reports: Exporting Azure resources with Powershell and Azure CLI

Wed, 28 Apr 2021 17:31:36 +0200

Azure Reports: Exporting Azure resources with Powershell and Azure CLI

A common scenario when we work with DevOps and cloud is the need to export information about your resources. In this post, I’ll show the simplest way to extract that with the command line.

The idea of this post is to show the mechanism behind the extraction, I’ll run a simple command to recover the resources and choose some columns to export to a CSV file. You can use this as a base of more complex reports to handle properties, cross with other information, etc.

The first step is to connect in our Azure Account using Azure CLI (you can also do it using Azure Powershell), and recover all resources in our subscription:

Then we create an Array List to populate, iterate on the resources recovered above, and add the needed fields on the array:

Now we create a file name based on date and time to export the populated array. In my case I’m using the Delimiter “;”, as in my favorite regionalization this is the default pattern for CSV files. If this is not your case, you can remove that parameter.

This is the complete script, including the outputPath parameter:

And this is the file exported:

This is the link for my GitHub repository, and the intention is to fill it with more complex reports :)

https://github.com/wesleycamargo/AzureReports

See you in the next post!

Deploying a DotNet Core app in Azure Web App by command line

Thu, 07 Jan 2021 09:01:16 +0100

Deploying a DotNet Core app in Azure Web App by command line

If you need to fast deploy your dotnet core App in Azure, but don’t want to configure an entire CI/CD Pipeline, check in this post on how to deploy it!

To deploy the web app we will use a simple DotNet Core MVC application.

First of all, let´s create some parameters to prepare our resources. We are using a random id to avoid create the resources with some existing name:

To create the app, we will use an MVC Sample in the dotnet core templates. If you already have an existing project to deploy, skip the first line. We will prepare the publishing package with the dotnet core publish command and then zip it in a file:

In Azure, we will create a resource group and an app service plan, that are pre reqs to run a WebApp.

And finally, execute the deployment in the WebApp created above.

How to collect Business Information in Application Insights

Sun, 03 Jan 2021 16:06:38 +0100

Monitoring - How to collect Business Information in Application Insights

Sometimes you have business requirements to know how many times something happened. An easy way to do that is by using Application Insights Telemetry. In this post, we will see how to do this configuration.

Creating the Azure Application Insights

Create a new Application Insights in your Azure account. You can create with the ARM Template below:

To run the ARM Template with Az CLI, you can use these commands:

az group create -n RG-Samples -l northeurope az deployment group create -g RG-Samples — template-file .\appInsights.jsonIt will return an Instrumentation Key as output, save this value to use later.

Creating the Asp Net Project

Create a new MVC application and add the package Microsoft.ApplicationInsights.AspNetCore:

dotnet new mvc dotnet add package Microsoft.ApplicationInsights.AspNetCoreNow in the Startup.cs file, we need to configure the Application Insights Telemetry.

Go to the method ConfigureServices and add the line services.AddApplicationInsightsTelemetry();

At the end of the file Views/Home/Index.cshtml add a button to call the event:

In the HomeController.cs, add a private variable with the type *TelemetryClient and *add to the constructor a variable to assign it. Also, add a new method to call your Event Button.

In the appSettings.json, replace the content as below and substituting the Instrumentation Key with the value collected in the steps above:

Collecting and searching data in Application Insights

Run the application with the command dotnet run and open https://localhost:5001 in your browser. Now click some times in Hello to generate data in the application insights:

In Azure Portal, open the Application Insights created, and click in search:

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.

Save Money with Azure: Handling your resources with Azure Functions

Sat, 01 Aug 2020 22:30:15 +0200

ONE OF THE INCESSANT THINGS WHEN WE USE CLOUD PROVIDERS, IT’S HOW TO HAVE THE BIGGEST EFFICIENCY WITH OUR RESOURCES. IF YOU HAVE AZURE VIRTUAL MACHINES, FOR EXAMPLE, REDUCE THE TIME OF NON-PRODUCTION ENVIRONMENTS STAYS TURNED ON TO 12 HOURS AT WEEKDAYS CAN REDUCE YOUR BILL BY 67%.

Save Money with Azure: Handling your resources with Azure Functions

In fact, when a VM is created, there is an option for shutdown within the scheduled time, but it’s a bit limited, due to nonexistence of an option to startup the VMs, nor the option to do this for dependent VMs as a Domain Controller that should be online when the other VMs start.

A good, simple, and cheaper solution for this, is to use an Azure Function to startup and shutdown the Virtual Machines. So let’s see how we can do it!

What you will need:

Azure Account
Visual Studio Code
VS Code — Azure Functions Plugin
An Azure Virtual Machine

Preparing the Virtual Machine

Now we need to create a beacon in the VMs that we need to shutdown/startup. For this function, we’ll use a tag shutdownDaily with the value true. Later we will filter the VMs with this tag and shut it down in the function script.

Creating the shutdown function.

Open the Visual Studio Code, and create a new Powershell Function:

Select the Timer Function option and give a name to the function:

Now we need to define how often the function will be executed. Here we will execute every day at 7 PM.

The Azure Functions use cron expression to define the frequency. (You can have more information here)

It will create a basic function based on a template. We just need to keep the parameter $Timer.

For ease, you can replace all code with the block below:

Publishing the function on Azure

Now let’s publish the function on Azure Account.

First Sign in to Azure. It will redirect you to a Microsoft Login Screen in your browser. Enter your credentials and go back to Visual Studio Code.

Click in the Upload Icon, and select the desired subscription to deploy:

Now create a new function, give a name, and select the region. It will create all resources with this name. If you need to change something, use the advanced mode. After creation it will deploy the code automatically:

Given permissions to the function

After creating the function, we need to authorize it to manipulate Azure Resources. On function Settings, open Identity menu and change the status to On and save this.

It will enable Azure role assignments button, touch this, and Add role assignment. Here I’ll create permission as a contributor int the subscription, but use the best approach to your environment:

Testing the function

To test the function open it and run:

Expand the Logs menu, and check if everything is ok :)

Creating a startup function.

For the startup function, create a new function and in the step to replace the auto-generated code, use the code below:

Conclusion

Thi’s a simple use with one Virtual Machine, but you can expand this, with more complex environments as dependent resources and uses for other resources.

I hope that it can be helpful to you!

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!

Pushing your code to GitHub and Azure Repos at the same time

Fri, 22 May 2020 06:33:08 +0200

Pushing your code to GitHub and Azure Repos at the same time

If you have an existing repository hosted by an Azure Repos or in GitHub, you can add new remotes easily. Let’s see how we can do it!

Creating and versioning a local project

Let’s create our project. In an empty directory type the CLI commands below:

It will create a new .net core web application, with a gitignore file and versioned in a local git.

Creating an Azure Repos repository and pushing your code

In your Azure DevOps account, follow these steps:

In the next screen disable the ‘Add a README’ option and enter your repo name:

In the empty repository created you have some options to push your code, we’ll push from an existing repository, so copy the command as the figure:

In your terminal paste the command, remember to check if you’re in your project directory. The highlighted log will confirm if your push was successful:

Refresh your Azure Repos page and your code was pushed!

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

How to send .Net Core NuGet packages to Azure Artifacts

Sat, 09 May 2020 04:49:34 +0200

How to send .Net Core NuGet packages to Azure Artifacts

Learn how you can send .net core NuGet packages to Azure Artifacts.

To increase reusability in our company, an interesting thing that we can consider is to share our packages. Using .net, both core or standard, you can consider NuGet as a package manager. The Azure DevOps has an implementation for a NuGet as a Service named Azure Artifacts.

In this post, I’ll show you how to deploy manually a NuGet package step by step.

Below are all commands used in this tutorial, but I’ll explain each one.

Let’s get the hands dirty!

Creating and configuring an application

To start, we need a .net core class library application. To do this, type on terminal:

dotnet new classlibIt will create a basic project with a .csproj and one class. Rename the class to Math and put the code below on this:

To send new packages, first, we need to configure a connection between our app and the feed that will be created. For now, we’ll add a nuget.config file in our project. On terminal type:

dotnet new nugetconfigA file like this will be created:

This is the standard NuGet feed, after create ours we will update this file.

Now let’s package the project in a NuGet package using this command:

dotnet packIt will create a nupkg file in the bin directory. We’ll use this later.

The project it’s done, now let’s create the feed.

Creating a new artifact feed with Azure Artifacts

Access your Azure DevOps account and follow the steps:

On the next screen click on Connect to feed:

Here is the connection information necessary to connect our app with the feed. Copy the Project setup content and update the value of the nuget.config created before.

Connecting to feed

To make the connection, we need to download and install a connection provider. Save the content below in a file and run:

After installing the credential provider, we can authenticate with Azure DevOps. In the previous section in Publish packages, it’s given to you command with your connection information, add the parameter interactive. It will be used to start a new browser session and do the authentication. Without this parameter, the command won’t work.

dotnet nuget push .\bin\Debug\NugetPackage.1.0.0.nupkg –source “MeuFeed” –api-key teste –interactiveIt will be provided a URL and code, open the URL in the browser, and paste the code there.

Enviando pacotes Nuget .Net Core para o Azure Artifacts

Fri, 08 May 2020 00:40:29 +0200

Enviando pacotes Nuget .Net Core para o Azure Artifacts

Aprenda como publicar packages nuget no Azure Artifacts!

Para podermos ter maior reusabilidade dentro de nossa empresa, é interessante a utilização de pacotes compartilhados. No caso do .net, tanto core como standart utilizam o Nuget como Gerenciador de pacotes.

Nesse post irei ensinar passo a passo para realizar a publicação manual de um pacote nuget.

Ao longo do post irei detalhar cada um deles, mas abaixo estão todos os comandos executados no terminal:

Agora vamos botar a mão na massa!

Criando e configurando a aplicação

Vamos iniciar criando uma aplicação do tipo class library no .net core. Para isso digite no terminal (se você não tem familiaridade com o .net core nesse post ensino como criar uma aplicação web no VS Code):

dotnet new classlibO projeto criado é bem básico, possuindo apenas um .csproj e uma classe. Renomeie a classe para Math e adicione o código abaixo:

Vamos empacotar o projeto em um nuget package executando o comando:

dotnet packSerá criado um arquivo nupkg na pasta bin. Usaremos ele mais tarde.

Para enviar novos pacotes precisamos realizar a conexão da nossa aplicação com o feed que vamos criar. Vamos então adicionar um arquivo nuget.config em nosso projeto. No terminal digite:

dotnet new nugetconfigSerá criado um arquivo em nosso projeto como este:

O feed configurado é o padrão, para adicionar as configurações do nosso feed, vamos criá-lo e obter as conexões.

Criando o feed de artefatos no Azure Artifacts

Acesse sua conta do Azure DevOps e siga os passos abaixo:

Na tela que irá aparecer clique em Connect to feed:

Aqui estão as informações de conexão que iremos utilizar. Copie o conteúdo de Project setup e substitua o valor do arquivo nuget.config que criamos.

Conectando ao feed

Para realizar a conexão, precisamos baixar um provider. Para isso abre uma nova janela no VS Code e copie o conteúdo do arquivo abaixo salvando como CredentialProvider.ps1 e execute:

Agora que foi instalado o Credential Provider vamos conseguir autenticar no Azure DevOps. Na seção anterior em Publish packages é disponibilizado um comando copie ele e não se esqueça de adicionar o parâmetro interactive. Ele serve para iniciar uma sessão no browser e realizar a autenticação. Sem ele o comando não irá funcionar.

dotnet nuget push .\bin\Debug\NugetPackage.1.0.0.nupkg –source “MeuFeed” –api-key teste –interactiveCopie e abra no browser a URL que será fornecida e copie o código:

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!

O que é Automação de Configuração e por que devo utilizar

Sat, 25 Apr 2020 23:14:58 +0200

O que é Automação de Configuração e por que devo utilizar

Se acidentalmente alguém destruir seu ambiente de produção agora, quanto tempo você gastaria para deixar tudo funcionando novamente?

Automação de configuração ou Continuous Configuration Automation (CCA) é um tipo de ferramenta de IaC que após o provisionamento dos recursos irão garantir que todas as configurações necessárias para que a aplicação funcione estão instaladas e configuradas corretamente no nosso ambiente.

No mundo de DevOps é muito comum ouvirmos falar sobre Infraestrutura como código (IaC), que nada mais é que provisionar a infraestrutura de nossas aplicações através de arquivos que são tratados da mesma forma que o código fonte.

Basicamente Infra as Code possui 2 tipos de ferramentas:

**Provisionamento de recursos **- nessa categoria estão ferramentas que criam os recursos de infraestrutura que serão utilizados por nossas aplicações. Entre as ferramentas mais conhecidas estão: AWS Cloud Formation, ARM Templates e talvez a mais conhecida de todos, o Terraform.
Continuous Configuration Automation (CCA) ou Configuração de ambientes - aqui estão ferramentas, como mencionado acima, que após a criação dos recursos irão garantir que todas as configurações necessárias para que a aplicação funcionem estejam de acordo com o especificado. Exemplos dessas configurações são, garantir que portas de firewall estejam liberadas, outros softwares que minha aplicação tenha dependência estejam instalados, servidores de aplicação onde minha aplicação irá rodar esteja com a versão correta do framework utilizado, permissões de acesso, entre todas as outras configurações necessárias para nosso ambiente. Aqui estão alguns exemplos dessas ferramentas: Chef, Puppet, Powershell DSC, Ansible entre vários outros. Aqui neste artigo demonstro a utilização básica do Powershell DSC.

Em algumas ferramentas é possível realizar as duas tarefas sendo assim você pode utilizar apenas uma, porém, sempre haverá especialização em uma das duas categorias (provisionamento ou configuração), o que pode dar um pouco mais de trabalho para a implementação na categoria menos especializada. Nesse caso deve ser avaliado o custo benefício de implementação vs valores gastos com licenças, por exemplo.

Mas por que eu preciso disso?

Acredito que hoje, 99% das as empresas devem utilizar algum tipo de controle de versão para manter seu software (se não está utilizando é melhor pensar nisso imediatamente!), entretanto, em grande parte esses sistemas são utilizados apenas para versionamento de código fonte, quando deveria englobar todos os artefatos necessários para recriar seus binários e ambientes.

Criar o ambiente da aplicação à qualquer momento

Para que em uma emergência seja possível recriar nosso ambiente com o mínimo de esforço, um dos princípios de DevOps é que devemos manter absolutamente TUDO que seja necessário para criarmos uma versão de nossa aplicação do zero em um sistema de Controle de Versão

Eu já presenciei essa experiência por duas vezes (não foi minha culpa heheh), e em ambas boa parte dos recursos estavam sim versionados, mas alguns como configurações de aplicação, regras de DNS, e alguns outros itens infelizmente não. A maior parte foi configurada razoavelmente rápido, mas por algumas semanas fomos descobrindo alguns itens de configuração que faltavam ou estavam incorretos.

Ambientes de desenvolvimentos padronizados

Acredito que todos na área de TI já ouviram a famosa frase “Na minha máquina funciona”.

Outra vantagem será garantir que todos os desenvolvedores utilizam um ambiente idêntico, com todas as dependências instaladas e configurações realizadas. Caso isso não seja implementado, poderá causar problemas como por exemplo, desenvolvedores utilizando versões diferentes de um framework, e ao juntar suas alterações ocorrerem conflitos que precisarão ser corrigidos, ou até mesmo alguma dependência de software que existe apenas no ambiente do desenvolvedor.

Controle das alterações realizadas nos ambientes

Com o versionamento das definições de configurações dos ambientes em arquivos armazenados em um **Sistemas de Controle de Versão **todas as alterações podem ser iniciadas através de alterações nos arquivos e enviadas ao SCV, o que nos fornece um registro de todas as mudanças realizadas no ambiente e remove a necessidade de acessar algum servidor para realizar alterações, já que todo o processo será realizado de forma automática, garantindo padronização dos ambientes.

Criando um DSC básico

Fri, 24 Apr 2020 22:54:25 +0200

Continuous Configuration Automation— Criando um arquivo DSC básico

Estou apoiando na implementação de Powershell DSC em um cliente, e sempre preciso de alguma referência para executar algumas operações.

Nesse primeiro post está um arquivo bem básico para ser utilizado como referência:

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!

Conectando WebApps a redes existentes

Sun, 05 Aug 2018 00:38:24 +0200

Conectando WebApps a redes existentes

Em algumas situações quando utilizamos WebApps pode ser necessária a comunicação com algum recurso já existente em nossa rede, como por exemplo um banco de dados IaaS, uma API, ou até mesmo um outro WebApp.

A maneira mais simples de realizar essa comunicação é através da internet, mas, apesar de ser mais fácil isso pode expor sua aplicação a vários riscos de segurança, como invasões, roubos de dados, etc.

Para solucionar esse problema, o Microsoft Azure possui um recurso chamado VNet Integration, que permite a conexão de um WebApp a uma rede existente.

Agora irei demonstrar como realizar a conexão:

Criando a Virtual Network (VNet)

Se você já possuir uma VNet pode pular para a próxima etapa. Para a criação não existem muitos segredos, a VNet pode seguir as configurações padrão sugeridas:

Após a criação da VNet, precisamos criar um VNet Gateway, que será utilizado para realizar uma conexão VPN Point to Site (P2S) do seu WebApp para a sua VNet, para isso é necessário adicionar uma subnet exclusiva para gateways. Vá em “Subnets” e clique em “Gateway subnet”:

Repare que a subnet é nomeada automaticamente, isso acontece pois no momento da criação do VNet Gateway ele irá buscar por esse nome:

Com a subnet criada, vamos à criação do Gateway.

Criando o Virtual Network Gateway

Em Gateway type selecione “VPN”, em VPN type “Route-based” e em Virtual network, escolha a VNet criada:

Essa etapa pode ser um pouco demorada, no geral demora em torno de 30 minutos para a criação do gateway.

Após criado vá em Point-to-site configuration, desabilite a opção IkeV2, e adicione a chave de um certificado do tipo CER. Este certificado será baixado automaticamente pelo WebApp para realizar a autenticação na VPN.

Ao realizar a configuração do WebApp para a conexão do Gateway, você poderá receber a mensagem de erro abaixo dizendo que o protocolo IkeV2 não é compatível, certifique-se que a opção está desabilitada conforme a imagem acima.

Conectando o WebApp

Assim como a VNet, caso já possua o WebApp vá para o próximo passo. Caso ainda não tenha, pode manter as configurações padrão.

Vá em networking e em VNet Integration clique em Setup, e depois escolha a VNet que possui o VNet Gateway:

Problemas comuns

Outro problema muito comum, é o certificado estar fora de sincronia:

Para resolver isso, vá ao Service Plan do seu WebApp, e force o sincronismo:

Após esses passos seu WebApp será capaz de acessar os recursos da sua rede!

Abraço!

Originally published at wesleycamargo.com.br on August 18, 2018.

Transformando configurações de XML e JSON com Web Apps

Sat, 31 Mar 2018 02:05:53 +0200

Transformando configurações de XML e JSON com Web Apps

Em um post anterior demonstrei como gerenciar configurações utilizando Azure Key Vault (clique aqui para ver). Agora irei mostrar como podemos realizar a transformação de uma configuração utilizando as tasks de deploy de Web Apps de uma maneira simples e fácil.

Configurando meu Web App

Para a utilização do recurso, crie um release definition e adicione uma task de Web App.

Na sessão “File Transforms & Variable Substitution Options” selecione “XML Variable Substitution”. Caso tenha arquivos .json que precisem ser alterados, especifique o caminho dos arquivos:

Neste exemplo, irei alterar a uma chave de configuração no arquivo web.config:

Adicione uma variável com o mesmo nome da key, neste caso “configuracao”, e o valor desejado da substituição:

No caso de arquivos json, deverá ser especificado o nó no nome da chave:

E após estes simples procedimentos basta salvar a release definition e iniciar um novo deploy e a transformação será realizada. Neste exemplo, a aplicação foi publicada em um Web App e o valor definido na variável foi transformado:

Abaixo está um tooltip da própria task explicando em quais situações será possível utilizar este recurso:

Conclusão

Antes da existência deste recurso, ou no caso de publicações que não utilizam WebApps, era necessário gerar um arquivo web.release.config, e alterar o valor para um token.

Com este novo processo, esta etapa não é mais necessária, onde precisamos apenas adicionar uma variável com o mesmo nome da key, e a task irá substituir os valores automaticamente.

Com isso o processo de gestão das configurações se torna muito mais rápido e eficiente!

Abraço!

Gerenciando transformações de configuração com Azure Key Vault e VSTS

Thu, 15 Feb 2018 16:21:22 +0100

Gerenciando transformações de configuração com Azure Key Vault e VSTS

Quem nunca teve dificuldade para fazer a gestão de arquivos de configuração que atire a primeira pedra!

Com a automação dos processos de build e deploy, uma etapa muito importante do processo é alteração das chaves dos arquivos de configuração, pois em cada um de nossos ambientes, teremos também valores diferentes, como por exemplo a connection string de um banco de dados.

Irei abordar uma maneira inteligente de realizar isso, através da transformação no momento do deploy utilizando o Azure Key Vault no momento de realização da Release no Visual Studio Team Services, então mãos a obra!

Para demonstrar, irei utilizar uma aplicação web simples, que será compilada no VSTS e publicada em um Azure Web App (em outro post irei explicar como criar e configurar um :)).

O que é o Azure Key Vault?

O Azure Key Vault é um recurso do Azure onde são armazenadas chaves e segredos para realizar a comunicação entre aplicações. Com ele podemos armazenar dados sensíveis(Segredos), Certificados .PFX, Key encription Keys (KEK) e também é possível utilizar sua API para realizar criptografia. Para mais informações à respeito, segue o link da documentação https://azure.microsoft.com/en-us/services/key-vault/

Entre as vantagens de utilização destacam-se:

Gestão de forma centralizada
Maior segurança na administração dos dados sensíveis
Maior facilidade na administração, pois pode ser feita no Azure Portal

Como implementar?

O primeiro passo é criar um Azure Key Vault no Azure Portal:

Selecione Add e na sequência preencha nome, Resource Group e Location. O restante das informações podem ser mantidas. Clique em Create:

Após a criação, selecione “Secrets” e “Generate/Import”:

Na próxima etapa iremos realizar a criação da chave/secret. Em Upload Options selecione Manual, e adicione o nome da variável e o valor. Note que por ser um secret aparecem asteriscos quando o valor é digitado:

Agora que temos nossa chave criada, vamos ao VSTS realizar a configuração de um Release Definition utilizando o Key Vault.

Para isso iremos utilizar um Variable Group e nele iremos realizar o link com o Key Vault.

Selecione a opção de Build/Release e em seguida Library. Após isso crie um novo Variable Group:

Agora devemos nomear o Variable Group e selecionar Link Secrets from an Azure Key Vault. Então selecione uma subscription e o Key Vault criado anteriormente. Após selecionar o Key Vault, será solicitada uma autorização para utilização, pode ser necessária uma permissão mais elevada no VSTS para relizar este passo:

Selecione as variáveis desejadas no grid que será habilitado e salve o Variable Group:

Para utilizar na Release Definition, vá em Variables e selecione Variable Groups. Clique em Link variable group:

Agora selecione o Variable Group criado, e clique em Link.

Pronto, agora as variáveis do Azure Key Vault podem ser utilizadas no processo de Release. Para utilizar, é o mesmo processo de utilização de uma variável criada durante a release, utilizando $(nomedavariavel) em algum script ou parâmetro.

Espero que este artigo seja útil, ajudando no processo de transformações de arquivos tornando mais prático e seguro!

Abraço!

Mon, 01 Jan 0001 00:00:00 +0000

Gerenciando transformações de configuração com Azure Key Vault e VSTS

Quem nunca teve dificuldade para fazer a gestão de arquivos de configuração que atire a primeira pedra!

Gerenciando transformações de configuração com Azure Key Vault e VSTS

Quem nunca teve dificuldade para fazer a gestão de arquivos de configuração que atire a primeira pedra!

Para demonstrar, irei utilizar uma aplicação web simples, que será compilada no VSTS e publicada em um Azure Web App (em outro post irei explicar como criar e configurar um :)).

O que é o Azure Key Vault?

Entre as vantagens de utilização destacam-se:

Gestão de forma centralizada
Maior segurança na administração dos dados sensíveis
Maior facilidade na administração, pois pode ser feita no Azure Portal

Como implementar?

O primeiro passo é criar um Azure Key Vault no Azure Portal:

Selecione Add e na sequência preencha nome, Resource Group e Location. O restante das informações podem ser mantidas. Clique em Create:

Após a criação, selecione “Secrets” e “Generate/Import”:

Agora que temos nossa chave criada, vamos ao VSTS realizar a configuração de um Release Definition utilizando o Key Vault.

Para isso iremos utilizar um Variable Group e nele iremos realizar o link com o Key Vault.

Selecione a opção de Build/Release e em seguida Library. Após isso crie um novo Variable Group:

Agora devemos nomear o Variable Group e selecionar Link Secrets from an Azure Key Vault. Então selecione uma subscription e o Key Vault criado anteriormente.
Após selecionar o Key Vault, será solicitada uma autorização para utilização, pode ser necessária uma permissão mais elevada no VSTS para relizar este passo:

Selecione as variáveis desejadas no grid que será habilitado e salve o Variable Group:

Para utilizar na Release Definition, vá em Variables e selecione Variable Groups. Clique em Link variable group:

Agora selecione o Variable Group criado, e clique em Link.

Espero que este artigo seja útil, ajudando no processo de transformações de arquivos tornando mais prático e seguro!

Abraço!

Mon, 01 Jan 0001 00:00:00 +0000

Transformando configurações de XML e JSON com Web Apps

Em um post anterior demonstrei como gerenciar configurações utilizando Azure Key Vault (clique aqui para ver). Agora irei mostrar como…

Transformando configurações de XML e JSON com Web Apps

Em um post anterior demonstrei como gerenciar configurações utilizando Azure Key Vault (clique aqui para ver).
Agora irei mostrar como podemos realizar a transformação de uma configuração utilizando as tasks de deploy de Web Apps de uma maneira simples e fácil.

Configurando meu Web App

Para a utilização do recurso, crie um release definition e adicione uma task de Web App.

Na sessão “File Transforms & Variable Substitution Options” selecione “XML Variable Substitution”. Caso tenha arquivos .json que precisem ser alterados, especifique o caminho dos arquivos:

Neste exemplo, irei alterar a uma chave de configuração no arquivo web.config:

Adicione uma variável com o mesmo nome da key, neste caso “configuracao”, e o valor desejado da substituição:

No caso de arquivos json, deverá ser especificado o nó no nome da chave:

Abaixo está um tooltip da própria task explicando em quais situações será possível utilizar este recurso:

Conclusão

Antes da existência deste recurso, ou no caso de publicações que não utilizam WebApps, era necessário gerar um arquivo web.release.config, e alterar o valor para um token.

Com este novo processo, esta etapa não é mais necessária, onde precisamos apenas adicionar uma variável com o mesmo nome da key, e a task irá substituir os valores automaticamente.

Com isso o processo de gestão das configurações se torna muito mais rápido e eficiente!

Abraço!

Mon, 01 Jan 0001 00:00:00 +0000

Conectando WebApps a redes existentes

Em algumas situações quando utilizamos WebApps pode ser necessária a comunicação com algum recurso já existente em nossa rede, como por…

Conectando WebApps a redes existentes

Para solucionar esse problema, o Microsoft Azure possui um recurso chamado VNet Integration, que permite a conexão de um WebApp a uma rede existente.

Agora irei demonstrar como realizar a conexão:

Criando a Virtual Network (VNet)

Se você já possuir uma VNet pode pular para a próxima etapa. Para a criação não existem muitos segredos, a VNet pode seguir as configurações padrão sugeridas:

Repare que a subnet é nomeada automaticamente, isso acontece pois no momento da criação do VNet Gateway ele irá buscar por esse nome:

Com a subnet criada, vamos à criação do Gateway.

Criando o Virtual Network Gateway

Em Gateway type selecione “VPN”, em VPN type “Route-based” e em Virtual network, escolha a VNet criada:

Essa etapa pode ser um pouco demorada, no geral demora em torno de 30 minutos para a criação do gateway.

Conectando o WebApp

Assim como a VNet, caso já possua o WebApp vá para o próximo passo. Caso ainda não tenha, pode manter as configurações padrão.

Vá em networking e em VNet Integration clique em Setup, e depois escolha a VNet que possui o VNet Gateway:

Problemas comuns

Outro problema muito comum, é o certificado estar fora de sincronia:

Para resolver isso, vá ao Service Plan do seu WebApp, e force o sincronismo:

Após esses passos seu WebApp será capaz de acessar os recursos da sua rede!

Abraço!

Originally published at wesleycamargo.com.br on August 18, 2018.

Mon, 01 Jan 0001 00:00:00 +0000

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:

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!

Mon, 01 Jan 0001 00:00:00 +0000

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…

DevOps é Automação - Mitos de DevOps

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

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

Mon, 01 Jan 0001 00:00:00 +0000

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…

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

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… 🤔

Mon, 01 Jan 0001 00:00:00 +0000

Criando um DSC básico

Garantir que exista uma pasta simples:

Continuous Configuration Automation— Criando um arquivo DSC básico

Estou apoiando na implementação de Powershell DSC em um cliente, e sempre preciso de alguma referência para executar algumas operações.

Nesse primeiro post está um arquivo bem básico para ser utilizado como referência:

Mon, 01 Jan 0001 00:00:00 +0000

O que é Automação de Configuração e por que devo utilizar

Se acidentalmente alguém destruir seu ambiente de produção agora, quanto tempo você gastaria para deixar tudo funcionando novamente?

O que é Automação de Configuração e por que devo utilizar

Se acidentalmente alguém destruir seu ambiente de produção agora, quanto tempo você gastaria para deixar tudo funcionando novamente?

Basicamente Infra as Code possui 2 tipos de ferramentas:

Provisionamento de recursos - nessa categoria estão ferramentas que criam os recursos de infraestrutura que serão utilizados por nossas aplicações.
Entre as ferramentas mais conhecidas estão: AWS Cloud Formation, ARM Templates e talvez a mais conhecida de todos, o Terraform.
Continuous Configuration Automation (CCA) ou Configuração de ambientes - aqui estão ferramentas, como mencionado acima, que após a criação dos recursos irão garantir que todas as configurações necessárias para que a aplicação funcionem estejam de acordo com o especificado. Exemplos dessas configurações são, garantir que portas de firewall estejam liberadas, outros softwares que minha aplicação tenha dependência estejam instalados, servidores de aplicação onde minha aplicação irá rodar esteja com a versão correta do framework utilizado, permissões de acesso, entre todas as outras configurações necessárias para nosso ambiente.
Aqui estão alguns exemplos dessas ferramentas: Chef, Puppet, Powershell DSC, Ansible entre vários outros. Aqui neste artigo demonstro a utilização básica do Powershell DSC.

Mas por que eu preciso disso?

Criar o ambiente da aplicação à qualquer momento

Ambientes de desenvolvimentos padronizados

Acredito que todos na área de TI já ouviram a famosa frase “Na minha máquina funciona”.

Controle das alterações realizadas nos ambientes

Com o versionamento das definições de configurações dos ambientes em arquivos armazenados em um Sistemas de Controle de Versão todas as alterações podem ser iniciadas através de alterações nos arquivos e enviadas ao SCV, o que nos fornece um registro de todas as mudanças realizadas no ambiente e remove a necessidade de acessar algum servidor para realizar alterações, já que todo o processo será realizado de forma automática, garantindo padronização dos ambientes.

Mon, 01 Jan 0001 00:00:00 +0000

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…

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 --version

No 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 webapp

Esse 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 run

Isso 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

dotnet new gitignore

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

git init

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:

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

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!

Mon, 01 Jan 0001 00:00:00 +0000

Pessoas - 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…

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

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.

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.

Objetivos únicos levam a uma única direção

Quando implementamos DevOps a união das pessoas significa que as mais diversas áreas da empresa não apenas desenvolvimento e infraestrutura, mas também QA, negócios, segurança, produtos, e qualquer outra área que seja necessária, devem possuir um objetivo em comum, como por exemplo, código estável de qualidade rapidamente em produção, e trabalhar em conjunto para alcançá-lo.

Com isso é possível criar um fluxo rápido e contínuo do trabalho planejado até produção e, ao mesmo tempo, obter qualidade, estabilidade, disponibilidade e segurança.

Assim são formadas equipes multidisciplinares, e utilizando as práticas de DevOps como, integração e entrega contínua, automação de testes, feedback contínuo, e monitoramento das aplicações e ambientes, serão responsáveis por todas as etapas da entrega (podendo ser software, ou qualquer outra forma de valor), e podem cumprir um objetivo único de desenvolver, testar e entregar software de forma independente, com segurança e confiabilidade, se preocupando com que a implantação de recursos ocorra de forma tranquila sem causar caos ou interrupções nas operações ou aplicações.

Existem outras aspectos que podem dificultar a implementação de DevOps, mas baseado na minha experiência, resolver esses conflitos e unificar os objetivos podem ajudar no sucesso da sua empresa!

E sua empresa, trabalha em conjunto para alcançar seus objetivos?

Até mais!

Mon, 01 Jan 0001 00:00:00 +0000

Enviando pacotes Nuget .Net Core para o Azure Artifacts

Aprenda como publicar packages nuget no Azure Artifacts!

Enviando pacotes Nuget .Net Core para o Azure Artifacts

Aprenda como publicar packages nuget no Azure Artifacts!

Nesse post irei ensinar passo a passo para realizar a publicação manual de um pacote nuget.

Ao longo do post irei detalhar cada um deles, mas abaixo estão todos os comandos executados no terminal:

Agora vamos botar a mão na massa!

Criando e configurando a aplicação

dotnet new classlib

O projeto criado é bem básico, possuindo apenas um .csproj e uma classe. Renomeie a classe para Math e adicione o código abaixo:

Vamos empacotar o projeto em um nuget package executando o comando:

dotnet pack

Será criado um arquivo nupkg na pasta bin. Usaremos ele mais tarde.

Para enviar novos pacotes precisamos realizar a conexão da nossa aplicação com o feed que vamos criar. Vamos então adicionar um arquivo nuget.config em nosso projeto. No terminal digite:

dotnet new nugetconfig

Será criado um arquivo em nosso projeto como este:

O feed configurado é o padrão, para adicionar as configurações do nosso feed, vamos criá-lo e obter as conexões.

Criando o feed de artefatos no Azure Artifacts

Acesse sua conta do Azure DevOps e siga os passos abaixo:

Na tela que irá aparecer clique em Connect to feed:

Aqui estão as informações de conexão que iremos utilizar. Copie o conteúdo de Project setup e substitua o valor do arquivo nuget.config que criamos.

Conectando ao feed

Para realizar a conexão, precisamos baixar um provider. Para isso abre uma nova janela no VS Code e copie o conteúdo do arquivo abaixo salvando como CredentialProvider.ps1 e execute:

dotnet nuget push .\bin\Debug\NugetPackage.1.0.0.nupkg --source "MeuFeed" --api-key teste --interactive

Copie e abra no browser a URL que será fornecida e copie o código:

Na URL irá aparecer a tela abaixo:

Se tudo ocorrer bem seu pacote aparecerá no seu feed:

Pronto! No próximo post da série irei ensinar como consumir os pacotes publicados no Azure Artifacts em uma aplicação .net core!

Valeu!

Mon, 01 Jan 0001 00:00:00 +0000

How to send .Net Core NuGet packages to Azure Artifacts

Learn how you can send .net core NuGet packages to Azure Artifacts.

How to send .Net Core NuGet packages to Azure Artifacts

Learn how you can send .net core NuGet packages to Azure Artifacts.

In this post, I’ll show you how to deploy manually a NuGet package step by step.

Below are all commands used in this tutorial, but I’ll explain each one.

Let’s get the hands dirty!

Creating and configuring an application

To start, we need a .net core class library application. To do this, type on terminal:

dotnet new classlib

It will create a basic project with a .csproj and one class. Rename the class to Math and put the code below on this:

To send new packages, first, we need to configure a connection between our app and the feed that will be created. For now, we’ll add a nuget.config file in our project. On terminal type:

dotnet new nugetconfig

A file like this will be created:

This is the standard NuGet feed, after create ours we will update this file.

Now let’s package the project in a NuGet package using this command:

dotnet pack

It will create a nupkg file in the bin directory. We’ll use this later.

The project it’s done, now let’s create the feed.

Creating a new artifact feed with Azure Artifacts

Access your Azure DevOps account and follow the steps:

On the next screen click on Connect to feed:

Here is the connection information necessary to connect our app with the feed. Copy the Project setup content and update the value of the nuget.config created before.

Connecting to feed

To make the connection, we need to download and install a connection provider. Save the content below in a file and run:

dotnet nuget push .\bin\Debug\NugetPackage.1.0.0.nupkg --source "MeuFeed" --api-key teste --interactive

It will be provided a URL and code, open the URL in the browser, and paste the code there.

In this URL you can see this box for type the code:

Finally, if everything will be ok you can see your package on the feed:

Done! In the next post, I’ll show how to consume this package in a .net core application.

See you!

Mon, 01 Jan 0001 00:00:00 +0000

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.

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.

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

Mon, 01 Jan 0001 00:00:00 +0000

Pushing your code to GitHub and Azure Repos at the same time

If you have an existing repository hosted by an Azure Repos or in GitHub, you can add new remotes easily. Let’s see how we can do it!

Pushing your code to GitHub and Azure Repos at the same time

If you have an existing repository hosted by an Azure Repos or in GitHub, you can add new remotes easily. Let’s see how we can do it!

Creating and versioning a local project

Let’s create our project. In an empty directory type the CLI commands below:

It will create a new .net core web application, with a gitignore file and versioned in a local git.

Creating an Azure Repos repository and pushing your code

In your Azure DevOps account, follow these steps:

In the next screen disable the ‘Add a README’ option and enter your repo name:

In the empty repository created you have some options to push your code, we’ll push from an existing repository, so copy the command as the figure:

In your terminal paste the command, remember to check if you’re in your project directory. The highlighted log will confirm if your push was successful:

Refresh your Azure Repos page and your code was pushed!

Creating a GitHub Repository and adding as a second remote

In your GitHub repository page, click on New:

Enter your repository name and click in Create repository:

As previously in Azure Repos, it will give you some options to push your code. Again we’ll use the push from an existing repository option, so again copy the code:

When we paste the code, we need to change your origin name. It’s necessary because we added an ‘origin’ before to another remote. I’ll rename it to gh-origin, but you can give whatever you want. Once again, if you see the highlighted message it means that you pushed your code:

Go back to your GitHub repo and refresh your page, and now you have two remotes to your repository!

Working with your remotes

The command used in the next session are these:

We can visualize all remotes added to our repo:

The secret here it’s in your origin, the standard it’s name this as ‘origin’. To send to Azure Repos, in our example we are using the standard. To push to GitHub we have to change to ‘gh-origin’.

I hope that it can be useful to you!

Mon, 01 Jan 0001 00:00:00 +0000

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…

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

When do I have to use this?

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

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:

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!

Mon, 01 Jan 0001 00:00:00 +0000

Save Money with Azure: Handling your resources with Azure Functions

In fact, when a VM is created, there is an option for shutdown within the scheduled time, but it’s a bit limited, due to nonexistence of…

ONE OF THE INCESSANT THINGS WHEN WE USE CLOUD PROVIDERS, IT’S HOW TO HAVE THE BIGGEST EFFICIENCY WITH OUR RESOURCES. IF YOU HAVE AZURE VIRTUAL MACHINES, FOR EXAMPLE, REDUCE THE TIME OF NON-PRODUCTION ENVIRONMENTS STAYS TURNED ON TO 12 HOURS AT WEEKDAYS CAN REDUCE YOUR BILL BY 67%.

Save Money with Azure: Handling your resources with Azure Functions

A good, simple, and cheaper solution for this, is to use an Azure Function to startup and shutdown the Virtual Machines. So let’s see how we can do it!

What you will need:

Azure Account
Visual Studio Code
VS Code — Azure Functions Plugin
An Azure Virtual Machine

Preparing the Virtual Machine

Creating the shutdown function.

Open the Visual Studio Code, and create a new Powershell Function:

Select the Timer Function option and give a name to the function:

Now we need to define how often the function will be executed. Here we will execute every day at 7 PM.

The Azure Functions use cron expression to define the frequency. (You can have more information here)

It will create a basic function based on a template. We just need to keep the parameter $Timer.

For ease, you can replace all code with the block below:

Publishing the function on Azure

Now let’s publish the function on Azure Account.

First Sign in to Azure. It will redirect you to a Microsoft Login Screen in your browser. Enter your credentials and go back to Visual Studio Code.

Click in the Upload Icon, and select the desired subscription to deploy:

Given permissions to the function

After creating the function, we need to authorize it to manipulate Azure Resources. On function Settings, open Identity menu and change the status to On and save this.

It will enable Azure role assignments button, touch this, and Add role assignment. Here I’ll create permission as a contributor int the subscription, but use the best approach to your environment:

Testing the function

To test the function open it and run:

Expand the Logs menu, and check if everything is ok :)

Creating a startup function.

For the startup function, create a new function and in the step to replace the auto-generated code, use the code below:

Conclusion

Thi’s a simple use with one Virtual Machine, but you can expand this, with more complex environments as dependent resources and uses for other resources.

I hope that it can be helpful to you!

Mon, 01 Jan 0001 00:00:00 +0000

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

Sometimes can be necessary to use more than one repository in our deployment pipelines. Maybe you are deploying resources from different…

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

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.

However, to checkout the second repository, we should create some additional steps:

Resources section - We need to add an additional section to reference the second repository. This section should be added to the root level of YAML file.

repository - The alias that we will use in the next steps inside the pipeline
type - The kind of repo (GitHub, git, Bitbucket, etc)
endpoint - Your GitHub Service Connection
name - Name of your repo in GitHub

Checkout section - By default in the steps section, we have an implicit checkout of the self repository. It means that we don´t need to add any additional step to download the repo that the YAML files is part of.

But as we need to checkout our second repo, we need to add these steps explicitly, including the self repo.

Self repository - The main repo containing the YAML file.
DevOpsTools - Name gave to your repo in the repositories section

In the end, our YAML Pipeline should look like the one below:

After to save the file, if we check the pipeline definition we can see that now we have our two sources:

And finally, when we run it, we can see our two checkout activities and the checkout of our second repository:

Both artifacts will be downloaded in the build artifacts directory. To consume it you can use the environment variable $(Build.ArtifactStagingDirectory).

I wish that it can be useful, and see you in the next post! =D

Mon, 01 Jan 0001 00:00:00 +0000

How to collect Business Information in Application Insights

Sometimes you have business requirements to know how many times something happened. An easy way to do that is by using Application…

Monitoring - How to collect Business Information in Application Insights

Creating the Azure Application Insights

Create a new Application Insights in your Azure account. You can create with the ARM Template below:

To run the ARM Template with Az CLI, you can use these commands:

az group create -n RG-Samples -l northeurope
az deployment group create -g RG-Samples — template-file .\appInsights.json

It will return an Instrumentation Key as output, save this value to use later.

Creating the Asp Net Project

Create a new MVC application and add the package Microsoft.ApplicationInsights.AspNetCore:

dotnet new mvc
dotnet add package Microsoft.ApplicationInsights.AspNetCore

Now in the Startup.cs file, we need to configure the Application Insights Telemetry.

Go to the method ConfigureServices and add the line `services.AddApplicationInsightsTelemetry();`

At the end of the file Views/Home/Index.cshtml add a button to call the event:

In the HomeController.cs, add a private variable with the type `TelemetryClient` and add to the constructor a variable to assign it. Also, add a new method to call your Event Button.

In the appSettings.json, replace the content as below and substituting the Instrumentation Key with the value collected in the steps above:

Collecting and searching data in Application Insights

Run the application with the command `dotnet run` and open https://localhost:5001 in your browser. Now click some times in Hello to generate data in the application insights:

In Azure Portal, open the Application Insights created, and click in search:

In Event types uncheck the box for `All` and check the `Custom Event`, now you can see your custom events collected =):

To see the full code, you can click here.

I hope it can be useful, and see you in the next post! =D

Mon, 01 Jan 0001 00:00:00 +0000

Deploying a DotNet Core app in Azure Web App by command line

If you need to fast deploy your dotnet core App in Azure, but don’t want to configure an entire CI/CD Pipeline, check in this post on how…

Deploying a DotNet Core app in Azure Web App by command line

If you need to fast deploy your dotnet core App in Azure, but don’t want to configure an entire CI/CD Pipeline, check in this post on how to deploy it!

To deploy the web app we will use a simple DotNet Core MVC application.

First of all, let´s create some parameters to prepare our resources. We are using a random id to avoid create the resources with some existing name:

In Azure, we will create a resource group and an app service plan, that are pre reqs to run a WebApp.

And finally, execute the deployment in the WebApp created above.

To make it easier below is a full version of the script:

See you in the next post!

Mon, 01 Jan 0001 00:00:00 +0000

Azure Reports: Exporting Azure resources with Powershell and Azure CLI

A common scenario when we work with DevOps and cloud is the need to export information about your resources. In this post, I’ll show the…

Azure Reports: Exporting Azure resources with Powershell and Azure CLI

A common scenario when we work with DevOps and cloud is the need to export information about your resources. In this post, I’ll show the simplest way to extract that with the command line.

The first step is to connect in our Azure Account using Azure CLI (you can also do it using Azure Powershell), and recover all resources in our subscription:

Then we create an Array List to populate, iterate on the resources recovered above, and add the needed fields on the array:

This is the complete script, including the outputPath parameter:

And this is the file exported:

This is the link for my GitHub repository, and the intention is to fill it with more complex reports :)

https://github.com/wesleycamargo/AzureReports

See you in the next post!

Mon, 01 Jan 0001 00:00:00 +0000

Creating a pretty git log

Do you know git lg command? Git log command is very helpful, but sometimes, it can be a bit tricky to have a good view of your history…

Creating a pretty git log

Using git pretty formats

To solve that you can increment the git log command with pretty formats. The following formats are how I like to use, but you can check more options in the documentation: https://git-scm.com/docs/pretty-formats.

And this is how it looks like:

Creating git alias

Type this command every time can be a bit complicated, but no one needs to memorize that :). We can create an alias with the command below:

Behind the scenes, the alias will change your git configurations adding a line to your ~/.gitconfig file. To check which are your current configuration you can execute the commandgit config — list . It will list all your configurations, to see only alias type git config — get-regexp alias .

So finally we can call the alias created with the git lg command :)

I hope it can be useful, and see you in the next post!

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

Mon, 01 Jan 0001 00:00:00 +0000

DataOps Automation — Accessing Databricks API with AAD Service Principal Name

Databricks is an Apache Spark tool for data engineering used to process and transform large amounts of data and explore running machine learning models.

In this post I’ll show how to call databricks API’s, an important resource to automate the deployment and resources creation.

Preparing Tokens

Yes, you read it right tokens in the plural, we need more than one token to perform authentication.

Creating AAD token

For this, I have created the function below, as we will use it more than once.

Preparing HTTP header

As I mentioned before, we need two AAD Tokens if our SPN is not added as a user into databricks.

The first token is a databricks token. To create that we need to provide the databricks resource id (2ff814a6–3304–4ab8–85cb-cd0e6f879c1d).

If your SPN is a user in your databricks workspace, only this token should be enough.

Creating the databricks Personal Access Token

With our header prepared, you just need to call the databricks API, consuming the methods that you need.

Complete Script

Below you can find the complete script, including the auxiliar functions :)

I hope it can help you, and see you in next post!

Mon, 01 Jan 0001 00:00:00 +0000

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.

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.

Image prepared by author

Project structure

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

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.

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! 😃

Mon, 01 Jan 0001 00:00:00 +0000

DataOps Automation — Creating Azure Data Factory with git integration using Bicep

An important feature available in Azure Data Factory is the git integration, which allows us to keep Azure Data Factory artifacts under…

DataOps Automation — Creating Azure Data Factory with git integration using Bicep

Image prepared by author

Azure Data Factory Git integration

Okay, but why do I need to use git on my ADF? To explain this, I’ll list some advantages that the git integration offers, taken from Microsoft’s documentation:

Source control

As your data factory workloads become crucial, you would want to integrate your factory with Git to leverage several source control benefits like the following:

Ability to track/audit changes.
Ability to revert changes that introduced bugs.

Partial saves

Collaboration and control

Better CI/CD

If you are deploying to multiple environments with a continuous delivery process, git integration makes certain actions easier. Some of these actions include:

Configure your release pipeline to trigger automatically as soon as there are any changes made to your ‘dev’ factory.
Customize the properties in your factory that are available as parameters in the Resource Manager template. It can be useful to keep only the required set of properties as parameters and have everything else hardcoded.

Better Performance

An average factory with git integration loads 10 times faster than one authoring against the data factory service. This performance improvement is because resources are downloaded via Git.

Git Integration is only for Development Environment

Creating Bicep templates for Azure Data Factory step by step

To keep the explanation simple, I’ll show each stage of the bicep file. Each stage is a deployable file that you can execute individually with the command

az deployment group create -f <your file>.bicep -g <your resource group>

In the end, we will have the complete file ready to use.

Creating Data Factory Workspace

Linking GitHub with Azure Data Factory

In this stage we achieve the first goal of this post: create the git integration. I include the parameters necessary to connect with a GitHub repo, and then a section into “properties”. Now lets check the parameters:

accountName - This is your GitHub/Azure DevOps account name.
repositoryName - Name of your repository, pay attention that you don’t need your account name at the beginning.
collaborationBranc - The branch that will be used to integrate your feature branches. It will depend on your branch stratety. For git flow, it should be developed branch, for GitHub Flow, master/main.
rootFolder - The folder in your repo where the databricks artifacts will be versioned.
projectName - This parameter is only used for Azure DevOps. It’s the Team Project name of your repo.
type - This parameter defines if your repo is hosted on GitHub or Azure DevOps. For GitHub, the value must be:

FactoryGitHubConfiguration

For Azure Devops the value is:

FactoryVSTSConfiguration

Image prepared by author

Checking the environments

An environment parameter.
Extract the content of repoConfiguration to an external variable.
Use a ternary if to check if the environment provided is development. If it is, then use the variable, if not, use an empty group.

Image prepared by author

The bicep file of this stage:

Linking GitHub or Azure DevOps to Azure Data Factory

Included a “User Friendly” parameter to indicate the type of the repo.
Check the type parameter and create a variable with the expected value.
Create two configurations, one for GitHub and one for Azure DevOps.
Include another ternary if nested into the first one

Image prepared by author

Below you can check the final bicep template:

Real life example

In this post, I am showing how to consume this Bicep Template into an Azure DevOps Pipeline.

I hope this post can help you to create your ADF in a more automated way, and see you in the next post!

References

Source control — Azure Data Factory | Microsoft Docs

Factories — Configure Factory Repo — REST API (Azure Data Factory) | Microsoft Docs

Microsoft.DataFactory/factories 2018–06–01 — ARM template reference | Microsoft Docs

Mon, 01 Jan 0001 00:00:00 +0000

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

The easiest way to publish/deploy Azure Data Factory artifacts

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

Photo by Andreas Felske on Unsplash

If you work with Azure Data Factory, you probably noticed that the deployment process for this tool is unique. It is different from an API or website deployment as it generates ARM Templates and certainly at some point in time questioned “Why is so difficult to deploy it?”. Well, it doesn’t have to be…

Data Factory CI/CD — the old (and problematic) flow

Azure Data Factory is a great orchestration tool for the Big Data process. It has many integrations and capabilities that make the Data Engineer life very easy.

Although when we talk about deployments there are some tricks, for example, the publish button inside the workspace, that is necessary to generate the ARM Templates to be deployed. Also, there is no deployment into the development environment, as you are already working there as an editor tool. This process’s a kind different comparing to other “traditional developments”, and this manual step sends shivers down DevOps engineers spines:

Deployment from Azure Data Factory Workspace — Image from Microsoft Docs

It often creates discussions and “workarounds” to deal with this manual step. In some solutions, people move the generate ARM Templates from the adf_publish manually to the feature branch and create a new commit. In others, there is an integration using more than one repo, but again, start the deployment should be - again - a manual step.

On the older approach, the best solution from my point of view is to deploy using Azure Powershell, but it creates additional complexity as you need to control manually all elements that should be deployed, like linked services and pipelines.

Data Factory CI/CD — the new (and much better) flow

Fortunately, there is a new way to generate the ARM templates to be deployed, and you don’t need the workarounds mentioned above.

In this strategy, you basically validate and “build” your Data Factory JSON files into ARM Templates ready to be used. To make it work, you need to create a build pipeline and consume the ADFUtilities NPM package. This is much cleaner and the manual steps disappear :).

Deployment with new Azure Data Factory flow — Image from Microsoft Docs

For more information, check the official documentation here.

How to Create Azure Data Factory using IaC

Infrastructure as Code

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.

Git Repository

Repository Structure

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:

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.

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

Development environment — Image by author

UAT and Production

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

I hope it can be useful!

Mon, 01 Jan 0001 00:00:00 +0000

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…

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?

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

az group create -name RG-Databricks -location northeurope

Replace 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 <your file> --outdir <your directory>

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

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

Databricks YAML Pipeline

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

Conclusion

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

Mon, 01 Jan 0001 00:00:00 +0000

Hello Eric, Alexandr is right, you need to pass the empty object to validation works.

Mon, 01 Jan 0001 00:00:00 +0000

How to suppress warning and error messages in Azure CLI

In Azure CLI some commands can return errors and warning messages, which can cause troubles on your script, so check out how to suppress it

How to suppress warning and error messages in Azure CLI

In Azure CLI some commands can return errors and warning messages, which can cause troubles on your script, so check out how to suppress it

Photo by Muhammad Daudy on Unsplash

How to suppress warnings on Azure CLI

Command group is in preview and under development

In some cases the CLI used can be under development and show the message: Command group is in preview and under development. Reference and support levels: https://aka.ms/CLI_refstatus

At the moment that I am writing this post, the az devops CLI variable-group for example is always returning the message above, which have been causing troubles and breaking my pester tests :)

Photo prepared by author

Quiet mode on Azure CLI

For Azure CLI, the simplest way to make the commands “quiet” is by adding the global parameter --only-show-errors in your command. It will suppress only the warnings and keep the message in case you have any errors during the execution.

So in our example for az pipelines variable-group our command will be like this:

az pipelines variable-group list --org $organization -p $project --only-show-errors

How to suppress errors on Azure CLI

Redirecting the console output STDERR

A common scenario to redirect streams is when the symbol > is used to write the output of the command in a file. It redirects the standard output - STDOUT - to the file added as a parameter.

In the situation that is necessary to suppress the errors, we need to redirect the output of the error stream — STDERR.

To do it you simply need to add 2>nul after the CLI command, which means that the second stream (STDERR) will be redirected to null .

So in our example for az pipelines variable-group the command will be:

az pipelines variable-group list --org $organization -p $project 2>nul

Conclusion

I grouped both, how to suppress warnings and errors in one place, so would be to choose which option suits better in each scenario.

References

Redirecting error from Command Prompt — Visual C++ | Microsoft Docs

https://github.com/Azure/azure-cli/issues/13384

Mon, 01 Jan 0001 00:00:00 +0000

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…

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

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

parameters:
 - name: applicationName
 type: string

Stages on Azure DevOps YAML Templates

Extending Azure DevOps YAML Templates

Configuring triggers on Azure DevOps YAML Templates

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

Referencing Azure DevOps YAML Templates

Image prepared by author

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 :).

Mon, 01 Jan 0001 00:00:00 +0000

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…

Delivery as Code with Azure DevOps Release Engine

Photo by Jackson Hendry on Unsplash

Everything as Code

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?

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?

What is Azure DevOps Release Engine

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?

Centralized Release definitions

Client/Application repositories

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

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

Azure DevOps Release Engine settings

Image by author

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.

Configuring resources to be deployed with Azure DevOps Release Engine

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.

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

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!

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

Mon, 01 Jan 0001 00:00:00 +0000

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…

Creating and publishing PowerShell Modules to Azure Artifacts with 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

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

Image by author

Replacing version number in nuspec and module manifest

Image by author

Packing PowerShell Module with NuGet

Image by author

Pushing PowerShell Module to Azure Artifacts

Image by author

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

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

Mon, 01 Jan 0001 00:00:00 +0000

Criando Azure Resource Group com Azure CLI

O Azure CLI é uma interface de linha de comando para o Azure. Ele pode ser usado com PowerShell ou em bash, com ele é possível criar…

Criando Azure Resource Group com Azure CLI

Photo by Milad Fakurian on Unsplash

Como conectar ao Azure com Azure CLI

Azure CLI - comandos para Account

Abaixo estão todos os comandos utilizados para realizar login e configurar a Azure Subscription para ser utilizada

Agora vamos ver os detalhes de execuçao dos comandos:

az -h — Lista os comandos disponíveis no Azure CLI

az login- Abre a página de login no browser para selecionar a conta que será conectada

az account list - Lista as subscription disponíveis
az account set -subscription - Seleciona a subscription que será usada
az account show - Exibe as informações da subscription atual

Como criar um Azure Resource Group com Azure CLI

Azure CLI — comandos para Resource Group

az group -h - Lista os comandos disponíveis para Resource Groups
az group create -h - Lista os argumentos necessários para criar um Resource Group

az group create --location -–name - Cria um Resource Group

az group list --output table - Lista Resource Groups da subscription em formato de tabela

az group delete --name- Apaga o Resource Group

Mon, 01 Jan 0001 00:00:00 +0000

The entry gate to Azure: Configuring your Azure subscription with Azure CLI

Azure CLI is a command line interface with Azure. It can be used in any command line prompt, including PowerShell and Bash, and it allows…

The entry gate to Azure: Configuring your Azure subscription with Azure CLI

Photo by Jan Tinneberg on Unsplash

How to set an Azure Subscription with Azure CLI

Azure CLI commands for Login and Account

Below is a summary of all commands used

Now let’s see the details of execution for each command.

How to know which commands to use in Azure CLI

Image by author

How to login into Azure with Azure CLI

The easiest way to login into Azure is using the interactive mode. It will open a new tab on your browser with the authentication page.

To do it run the command az login and choose your account:

Image by author

By default, after choosing your account it will prompt a list of available subscriptions on that account. These subscriptions can also be listed with the command az account list, described below.

How to set a subscription with Azure CLI

First, we need to see which subscriptions are available. To do it run the command az account list , this command will display all subscriptions available in your logged accounts.

Image by author

Ìmage by author

Conclusion

Although the commands are simple, they are very important, as they are an entry gate to interact with Azure.

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

Mon, 01 Jan 0001 00:00:00 +0000

First steps with Azure: Creating an Azure Resource Group with Azure CLI

An Azure Resource Group is a container that holds related resources for an Azure solution. This is an important resource in Azure and in…

First steps with Azure: Creating an Azure Resource Group with Azure CLI

Photo by Simon Infanger on Unsplash

What is Az CLI?

What is an Azure Resource Group

According to Microsoft documentation, this is the definition of an Azure Resource Group:

A resource group is a container that holds related resources for an Azure solution. The resource group can include all the resources for the solution, or only those resources that you want to manage as a group. You decide how you want to allocate resources to resource groups based on what makes the most sense for your organization. Generally, add resources that share the same lifecycle to the same resource group so you can easily deploy, update, and delete them as a group.

For more information, you can check the official documentation here.

Az CLI commands for Azure Resource Group

Azure Resource Group - Summary of commands

Below there is a summary of all commands used in this tutorial. You can copy it and replace the values between <> to your own values :)

How to use Az CLI Help?

az group help — Image by author

How to list existing Azure Resource Groups with Az CLI

az group list — Image by author

How to create an Azure Resource Group with Az CLI

To create a new Azure Resource Group, it is necessary to provide two required information:

Location: The Azure Region where your resource group will be created.
Name: The name of your Resource Group

The final command is az group create --location <location of your resource group> --name <name of your resource group> . Replace the content between <> with your own values .

az group create — Image by author

To check additional options use the command az group --help .

After creation, run again the command az group list --output tableto check if the resource group is shown.

az group list — Image by author

How to show details of an Azure Resource Group with Az CLI

az group show — Image by author

How to delete an Azure Resource Group with Az CLI

After the conclusion of the command, after running the list command the created resource group is not listed anymore.

Conclusion

The Resource Groups are an important part of Azure and automating its creation is a fundamental part of a DevOps process.

See you in the next post!

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

Mon, 01 Jan 0001 00:00:00 +0000

It’s time to tidy up your code: How to use Visual Studio Code Autoformat

If you are like me and like to have consistency in formatting your code, this is definitely a must to have configuration.

It’s time to tidy up your code: How to use Visual Studio Code Autoformat

Photo by Jozsef Hocza on Unsplash

If you are like me and like to have consistency in formatting your code, this is definitely a must to have configuration.

By default, you can use VS code formatters with the shortcut Alt+Shift+F but, you can also configure it to format every time you save your file, like this:

How to enable autoformat on Visual Studio Code

There are two options to enable autoformat by UI and editing settings.json file, let’s check both:

How to edit autoformat option on VS Code User Interface

Open the menu File->Preferences->Settings and under Text Editor look for Formating and enable the option Format On Save choosing which option is better on Format On Save Mode .

How to edit autoformat option on VS Code settings.json

To find settings.json file, open your Visual Studio Code and press F1:

Now type settings.json , open the file and add the section:

For the configurationFormat On Save Mode you can pick of the of the options below:

file
modifications
modificationsIfAvailable

This is how your file should look like:

This configuration applies to most part of the supported languages, like PowerShell, JSON, C#, and others.

How to autoformat Terraform files on Visual Studio Code

To do it, open again the settings.json file and add the following sections:

Pay attention that you must add one section for Terraform, and one more for terraform-vars.

This is the final file:

Conclusion

Autoformatting is an easy and helpful option that will for sure help your team to have consistency and keep your codebase tidy and clean.

See you in the next post!

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

Mon, 01 Jan 0001 00:00:00 +0000

Creating Infrastructure as Code for Azure with Azure Bicep step by step

One of the natural steps towards DevOps and Cloud Adoption is to create your Infrastructure using Code. For Azure, the most convenient…

Creating Infrastructure as Code for Azure with Azure Bicep step by step

Photo by Arisa Chattasa on Unsplash

What is Azure Bicep?

According to Microsoft Documentation, this is the definition of Bicep:

Bicep is a domain-specific language (DSL) that uses declarative syntax to deploy Azure resources. In a Bicep file, you define the infrastructure you want to deploy to Azure, and then use that file throughout the development lifecycle to repeatedly deploy your infrastructure.

How to create an Azure Resource Group with Azure Bicep?

Usually, one of the firsts resources on Azure that we need to create is a Resource Group, as it will group all other resources, and make it easier to administrate.

Create an Azure Resource Group using Azure Bicep it is quite simple, you need just the name of the resource group and the location that it will be created. Additionally, it is necessary to define the targeScope as a subscription, it will be explained in more detail below.

It is possible to deploy it in different ways, using Azure PowerShell, Azure CLI, or even Azure API’s. In this example, we will use Azure CLI to execute the deployment.

How to execute an Azure Resource Group deployment with Azure Bicep and Azure CLI?

On the latest versions of Azure CLI, there are different commands to run deployments against different scopes on Azure. To create Azure Resource Groups, it is necessary to use the subscription scope, which was also defined on the bicep template above.

The command used is az deployment sub create :

After running the script, we can check the resource group with the command az group show --name rg-bicepdemo :

Image by author

How to create an Azure Storage Account with Azure Bicep and Azure CLI?

To create resources on Resource Group scope, the Azure CLI command used must be az deployment group create :

To check the Storage Account creation run the command az storage account show --name stbicepdemo

Image by author

As they are in different scopes, it is not possible to run both bicep files with one command, however, I prepared a PowerShell script to run them in sequence:

Conclusion

See you in the next post!

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

Mon, 01 Jan 0001 00:00:00 +0000

Como funcionam os Loops — Developer BR — Corujinhas

Loops

Como funcionam os Loops — Developers BR — Corujinhas

Loops

O que é um loop ou laço?

Um loop é uma maneira de executar um trecho código repetidas vezes. É composto de uma condição e o código que será executado.

O loop é representado por um circuito fechado, e enquanto a condição não for satisfeita se repete infinitamente.

Condições de um loop

Verdadeiro ou Falso
Um número específico de vezes
O número de elementos em uma coleção

Código

Quando usar um loop

Usamos loops quando precisamos fazer a mesma coisa várias vezes. Vamos a um exemplo:

Imagine que estamos criando um sistema para uma cafeteria. Os requisitos para esse sistema são:

Para cada novo café pedido escrever na tela o número do pedido que está sendo executado
Ao final exibir a quantidade total de cafés preparados

Para simplificar, vamos imaginar que temos 3 pedidos de café e precisamos executá-los. Como seria esse código?

int cafesPreparados = 0;

// Preparando o café
cafesPreparados++;
Console.WriteLine($"Preparando o 1° café");

cafesPreparados++;
Console.WriteLine($"Preparando o 2° café");

cafesPreparados++;
Console.WriteLine($"Preparando o 3° café");

Console.WriteLine($"Total de devs felizes: {cafesPreparados}");

Não parece tão complicado, certo? Realmente, se tivermos poucos pedidos não é uma tarefa difícil, mas temos dois problemas:

No caso de apenas 3 pedidos, foram apenas mais 6 linhas de código, mas e se fossem 100? Ou 1000? Teremos um programador bem entediado repetindo esse código tantas vezes…
Além do problema acima, de termos tarefas repetitivas, nós adicionamos dentro do código cada pedido feito - O que impede de recebermos pedidos dinamicamente e na pratica inviabiliza a aplicação.

Mas imagine que agora nossa cafeteria aceita pedidos online, e recebeu 10000 pedidos. Como fazer isso?

É nessa situação que os loops vão te ajudar!

Tipos de loops

While

As principais características do while são:

Enquanto uma condição for verdadeira(ou falsa), continue repetindo.
Executa o trecho de código uma vez, volta ao inicio e verifica se a condição continua verdadeira e executa novamente.
Atenção! Isso pode acontecer para sempre, desde que a condição continue verdadeira! Isso é chamado de loop infinito e na maioria dos casos não é desejado.

Console.WriteLine("Quantos devs precisam de café?");
int devs = Convert.ToInt32(Console.ReadLine());

int cafesPreparados = 0;

while (cafesPreparados < devs)
{
 cafesPreparados++;
 Console.WriteLine($"Preparando o {cafesPreparados}° café");
}

Console.WriteLine($"Total de devs felizes: {cafesPreparados}");

Do While

Para do while, acontece o oposto, o código é executado e apenas após a condição é verificada. Isso pode ser útil em casos onde pelo menos uma execução é sempre necessária.

Console.WriteLine("Quantos devs precisam de café?");
int devs = Convert.ToInt32(Console.ReadLine());

int cafesPreparados = 0;

do
{
 cafesPreparados++;
 Console.WriteLine($"Preparando o {cafesPreparados}° café");
} while (cafesPreparados < devs);

if (cafesPreparados > devs)
{
 Console.WriteLine($"Oh não! O café está esfriando e nenhum dev está por perto!");
}
else
{
 Console.WriteLine($"Total de devs felizes: {cafesPreparados}");
}

For

Inicializar: Declaramos o valor inicial do índice
Condição: Adicionamos a comparação que será usada para parar o loop
Iterar: Incrementamos o índice, normalmente com ++

Console.WriteLine("Quantos devs precisam de café?");
int devs = Convert.ToInt32(Console.ReadLine());

int cafesPreparados = 0;

for (int i = 0; i < devs; i++)
{
 Console.WriteLine($"Preparando o {i}° café");
 cafesPreparados = i;
}

Console.WriteLine($"Total de devs felizes: {cafesPreparados}");

Foreach

O foreach é recomendado quando trabalhamos com coleções ou listas. Sua tradução é “para cada”, o que significa o trecho de código será repetido uma vez para cada elemento da lista.

var developers = new List<string>();
string maisdevs = "s";

do
{
 Console.WriteLine("Digite o nome do dev:");
 developers.Add(Console.ReadLine() as string ?? string.Empty);

 Console.WriteLine("Mais algum dev precisa de café? [S/N]");
 maisdevs = Console.ReadLine() as string ?? string.Empty;
} while (maisdevs.ToLower().Equals("s"));

foreach (var dev in developers)
{
 Console.WriteLine($"Preparando café para o dev {dev}");
}

Console.WriteLine($"Total de devs felizes: {developers.Count}");

GitHub do Corujinhas

Para os exemplos completos, veja o repositório do corujinhas no GitHub!
Developers-BR/corujinhas (github.com)

Mon, 01 Jan 0001 00:00:00 +0000

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…

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?

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

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:

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

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

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

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

🚀Join FAUN & get similar stories in your inbox each week

Mon, 01 Jan 0001 00:00:00 +0000

How to setup your environment with git and VS Code with choco

Configuring your git environment is something very important to begin using version control. In this post, I will show you, step by step…

How to setup your environment with git and VS Code with choco

Photo by Yancy Min on Unsplash

How to install git and Visual Studio Code with PowerShell and Choco

How to install Chocolatey with PowerShell

Before we proceed with git and VSCode, first we need to install the Chocolatey. Chocolatey, or simply Choco, is a package installer designed for work with PowerShell.

The easiest way to install choco is by running a PowerShell script in your terminal. Below I have prepared a script that calls the official Choco script on its site:

How to install git on Windows using choco

After the installation, check if git was correctly installed with the command git -v :

If you receive an error saying that git is not installed, close and reopen your terminal, it will reload the environment variables with the correct git path.

How to install Visual Studio Code with choco and PowerShell

As well we saw to install git, the command to install VSCode with choco and PowerShell is also very simple:

To check the installation, use the command code -v . Again, in case of any problem, close and reopen your terminal.

How to setup git credentials

How to setup git username and email

To associate your identity with your commits, it is necessary to define your git user name and email. You can configure it in different scopes, below we can see how to configure it globally:

How to setup Visual Studio Code as the default git editor

How to install and configure Git and VS Code with PowerShell Script

Installation

Configuration

Conclusion

Source control is the basis of any DevOps process, and git is currently the most used tool for it. Using the right configuration together with VS Code will help to start this journey!

References

Git — Installing Git (git-scm.com)

Chocolatey Software Docs | Chocolatey — Software Management for Windows

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

🚀Join FAUN & get similar stories in your inbox each week

Mon, 01 Jan 0001 00:00:00 +0000

How to create commits with different users in git

In my previous post, I showed among other stuff how to configure your git credentials. But in case you need to use different users in…

How to create commits with different users in git

Photo by Yancy Min on Unsplash

Understanding the git configuration

The git configuration is used to introduce customized behaviors on git and it has three different scopes of settings:

System — In this scope, the settings are applied to all users and all repositories. To edit this scope use the parameter --system . To verify which configurations are in the system scope, type the command git config --system -l
Global — This is the user scope, where it is possible to customize settings using the parameter --global , and it is applied to all repositories of that user. The global configuration file sits in the user directory on your computer.
Local— Each repository can also have its own customized settings. It is possible to find the configuration file in the git directory inside each repository ./.git/config , or it is also possible to check with the parameter--local .

It is possible to trace back from where the configuration is coming from: git config -l --show-origin

Different scopes of configuration — Image by author

In our case, we will play around with the user's configurations. These configurations are stored in a file .gitconfig that sits in your user directory, as mentioned above. To easily access it, you can type ~/.gitconfig in your terminal and you will be able to see something similar to this:

Creating the conditional includes in gitconfig

Concluding…

This configuration is quite simple, but can be very helpful if you work in many projects simultaneously . I hope it can help somehow 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 & get similar stories in your inbox each week

Mon, 01 Jan 0001 00:00:00 +0000

How to create a dotnet core project with command line

In this post, we will see how to simply create a dotnet core application using the command line. For that, we will use Windows Terminal…

How to create a dotnet core project with command line

Photo by Vipul Jha on Unsplash

Installing dotnet core with command line

Install dotnet core with the command line is quite simple. For that, we will use Winget with the command below:

Creating dotnet project in Windows Terminal

For this post, we will use Windows Terminal, but you can use any terminal that you want.

Open the terminal in the directory that you want to create your project and type the command dotnet new webapp -n demo . It will generate a directory called “demo” within the project structure.

Enter into the directory created and type code . . This command will open the Visual Studio Code in your project directory:

In the VS Code is possible to see the project structure, as we can see below:

How to build and run a dotnet core project locally

Now let’s build our dotnet project to ensure everything is working properly. The easiest way to do that is using the integrated terminal in VS Code.

To open the terminal type ctrl + ` or go to View > Terminal. In the terminal that will appear at the bottom of your VS Code, type the command dotnet build . If everything goes well you should see the Build succeeded message.

We can now run our web app with the command dotnet run . It will start the web app locally in some ports. You can copy one of them and open it on your browser:

Conclusion

In further posts, we will see more about DevOps practices, and having a real application to start with is crucial to understand all the steps that will be applied in a real-life scenario.

I hope this post could be useful and see you in the next one!

Mon, 01 Jan 0001 00:00:00 +0000

Git Basic commands in a nutshell

Without a doubt, git is the most popular Version Control System nowadays. There is a big chance that everyone who works with IT already…

Git Basic commands in a nutshell

Commit workflow — Image from Git Docs

At the end of the post, I will let all commands used with the description of them.

Prerequisites

git
Visual Studio Code
dotnet core
Windows Terminal

Git and Visual Studio Code

Git and Visual Studio Code are the main tools that we will be using in this post, so if you do not have it already configured, in this post, I describe how to set it up.

Creating a dotnet core project

How to configure git locally

Initializing a git repository

It is possible to initialize the git repository by either the user interface or the command line, which one is better, depending on your personal preferences. Below you can see both options:

For the command line, simply type the command git init . And that’s it! Quite simple as I promised :).

What is the .git directory?

.git directory — Image prepared by Author

To verify how the files are being tracked by git, click on the git icon on the left menu. After that, it is possible to see all files under “Changes”

What are the basic git commands for local repositories

ignoring files

To solve this problem you need to create a .gitignore file, with instructions on which files you don’t want to keep versioned.

To create this file, as we are using a dotnet core application as an example, in the VS Code terminal, ensure that you are in the root directory of your repository and type dotnet new gitignore.

You can see that among others, the folders binand obj are listed, which is what we want in our case.

stage — Adding files to stage with git

Staging is an intermediate area where you keep your changed files before you finish the commit. It allows you to review and format them, and also makes it easy to commit your files partially.

Commit workflow — Image from Git Docs

The command git add is used to add the files to the staging area. You can add file by file specifying the name git add <your file name>, or you can add all files at once with git add .

In our project, let’s first add the gitignore that we created in the session above. It will prevent adding any undesired files that are already generated.

Now that the gitignore is already there, we can add the remaining files with git add . .

Recording your changes with git commit

Finding the status of your changed files

Using git log to show your history

You can also customize the results, one of my favorites is to show all commits in one line, for this you can use git log — pretty=oneline.

Creating and moving among git branches

In the DevOps community, there are polemic discussions that branching is a bad practice that avoids real continuous integration, but this is not the topic that we are approaching today.

Independent if it is a good practice or not, branches are very useful for many situations and it’s worth having it in your toolbox.

When a repository is created, it always creates a default branch, which can be called master or main depending on your preferences, and both can be used as stable branches or baselines.

It is fairly common to create branches called features, so it is possible to work without interfering with the stable branch.

To create a new branch use the command git branch <branch name> or git checkout -b <branch name> . Personally, I prefer the second option, as it already switches to the newlywed-created branch.

Imagine that after some commits on your feature branch for some reason you want to move back to master, so the git checkout <branch name>command will be moving from one branch to another.

All basic git commands gathered

As promised, below are all commands used in this post:

Key take aways

Git is a foundation of mostly modern development, and starting with it is quite simple. I hope that with this commands list you will help you move forward with the IT world!

How to create a dotnet core project with command line | by Wesley Camargo | Oct, 2022 | Medium

How to setup your environment with git and VS Code with choco | by Wesley Camargo | Oct, 2022

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

🚀Join FAUN & get similar stories in your inbox each week

Mon, 01 Jan 0001 00:00:00 +0000

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…

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

Photo by Louis Hansel on Unsplash

What is Azure DevOps Pipelines?

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
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.

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.

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

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

Mon, 01 Jan 0001 00:00:00 +0000

Don’t repeat yourself! Creating Azure Bicep modules 💪

Since our Infrastructure is Code now, why don’t we leverage the best software development practices? Check out this post on achieving…

Don’t repeat yourself! Creating Azure Bicep modules 💪

Since our Infrastructure is Code now, why don’t we leverage the best software development practices? Check out this post on achieving reusability on your IaC templates using Bicep Modules!

Photo by Prateek Katyal on Unsplash

What are Azure Bicep Modules?

Bicep Modules are the application of the Don’t Repeat Yourself principle, where a Bicep template calls another Bicep template. As a result, this practice enables the reusability of existing code and can speed up the creation of future resources.

How to create an Azure Bicep Module?

How to consume an Azure Bicep Module?

Declaring a Bicep Module

When working with Bicep Modules, the syntax changes compared to resources. Instead of declaring resourcethe declaration is now module. Additionally, it is necessary to reference the module path, which can be local or remote.

Image prepared by the author

It is also mandatory to add a symbolic name to the resource. The symbolic name can be used to recover an output from the module to be used in another part of the template.

Image prepared by the author

The property name is mandatory. It will become the nested template name in the final template.

Image prepared by the author

Passing parameters to Bicep modules

Image prepared by the author

How to deploy an Azure Bicep Module?

Deployment of Bicep Modules works exactly like Bicep Templates. It is possible to use Azure CLI, Azure PowerShell, or even through Azure API.

I explain in more detail in this post how to deploy using Azure CLI. Below we can see the script used to deploy the templates and modules created above.

After running it is possible to see in the deployments of Azure Resource Group the main.bicep deployment:

Image prepared by the author

And if we click on the nested storage deployment we can observe the resource storageAccount being deployed :

Image prepared by the author

Conclusion

I hope this helps you, and see you at the next one!

👋 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

Mon, 01 Jan 0001 00:00:00 +0000

Optimize Your Cloud Environment with Azure Platform Landing Zones

What are Azure Landing Zones and why are they important?

Optimize Your Cloud Environment with Azure Platform Landing Zones

Photo by Pascal Meier on Unsplash

What are Azure Landing Zones and why are they important?

An Azure Landing Zone is the same as the house foundation, with essential services to support your platform or applications.

Azure Platform Landing Zones

Azure Platform Landing Zone

Microsoft divided the Platform Landing Zones into 8 design areas. These design areas are topics that must be carefully planned to ensure the security and performance of the platform:

Billing and Active Directory —Billing is the process of tracking and paying for the resources used in an Azure environment. The Azure billing and cost management platform provide the ability to monitor usage and costs, set budgets and alerts, and optimize spending. Azure Active Directory is a cloud-based identity and access management service that provides centralized identity management and robust security features.
Identity and access management — IAM controls access to Azure resources. Azure Active Directory is the main service used for IAM and helps manage user identities, groups, and access to cloud-based apps.
Network topology and connectivity — It deals with the design and communication between virtual network resources. A good design ensures secure and efficient communication and access to the internet and external resources.
Resource organization — It involves grouping and managing resources within an Azure environment. It provides structure and scalability, making it easier to manage and control resource access. Resource groups, subscriptions, and policies to improve efficiency are used to reduce complexity, making it easy to adminstrate and ensure policy compliance in the platform.
Security — This is one of the most important design areas when planning the landing zone. It involves protecting resources with a multi-layered approach, including access control, network security, encryption, and incident response planning.
Management — Management in Azure Landing Zones covers processes and tools used to manage and maintain resources. A well-managed landing zone needs clear roles, a change management process, and a structured approach to resource management.
Governance — This is about setting the rules to keep your Azure environment organized and secure. Azure has tools like Policy and Role-Based Access Control to enforce your policies. To make things easy, make sure roles are clear and have a plan for making changes.
Platform automation and DevOps — As I am a DevOps guy for almost 10 years, I am suspicious to talk about this topic :D. It basically ensures that tools and processes make the deployment and management of applications and infrastructure easier and faster.

Conclusion

👋 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

Mon, 01 Jan 0001 00:00:00 +0000

From Terraform to Azure Bicep: What You Need to Know about syntax

Hey there Terraform experts! I am confident that you know the power of infrastructure as Code in managing and provisioning IT…

From Terraform to Azure Bicep: What You Need to Know about syntax

Photo by Botond Czapp: https://www.pexels.com/photo/birds-flying-on-blue-sky-7255793/

Introducing Terraform and Bicep

Terraform and Azure Bicep are two popular Infra as Code (IaC) tools that allow developers and operations teams to manage and provision cloud infrastructure using development practices.

Language and Syntax

Image prepared by the author

Now let’s analyze the main differences:

Provider

As Bicep is designed specifically for Azure, the provider statement is not required.

Input

Local variables

locals {
 resource_group_name = "myTerraformResourceGroup"
 location = "West Europe"
}

On Bicep, it is not necessary to have a specific session, being possible to declare anywhere in the file (although is recommended to do in the beginning to make it more readable). It also makes the syntax a little simpler than in terraform var location = ‘westeurope’

Resources

Although the concepts are quite the same, the syntax is slightly different as we can see below:

Terraform resource:

resource "azurerm_storage_account" "storage" {
 name = var.storage_account_name
 resource_group_name = local.resource_group_name
 location = local.location
 account_tier = "Standard"
 account_replication_type = "LRS"
}

Bicep resource:

resource storage 'Microsoft.Storage/storageAccounts@2022-09-01' = {
 kind: 'StorageV2'
 location: location
 name: storageAccountName
 sku: {
 name: 'Standard_LRS'
 }
}

Output

output "storage_account_name" {
 value = azurerm_storage_account.storage.name
}

Bicep is again, slightly simple. No brackets and you can reference by the alias directly, without having to declare the resource type. In Bicep is also possible to assign a type in the output, which is useful in some cases.

output storageName string = storage.name

Terraform storage account example

Bicep storage account example

Conclusion

👋 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

Mon, 01 Jan 0001 00:00:00 +0000

Happy to help Thiago!

Mon, 01 Jan 0001 00:00:00 +0000

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…

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

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

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
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

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

Mon, 01 Jan 0001 00:00:00 +0000

Getting Started with Azure: What are Azure Virtual Machines and how to create it using Terraform

Azure VMs are like your own computer on the cloud. You can choose between different Operational Systems, such as Linux and Windows, and…

Getting Started with Azure: What are Azure Virtual Machines and how to create it using Terraform

Photo by imgix on Unsplash

What do I need to create a Virtual Machine on Azure?

To create the VM there are a few Azure resources that are necessary to be created before, as we can see in the image below:

Resources that are Pre-requisites

Resource Group: A resource group works similarly to a folder, where you can group the resources that have something in common. It can be resources of the same type, such as VMs, or the most recommended, resources that share the same life cycle.

Virtual Network: In an Azure VNet, you are able to create a private space, where your resources can communicate securely. It works similarly to the network that you are connected to right now to read this post, but it sits on Azure.

Subnet: They are subdivisions of a Virtual Network, helping to keep organized and segmented by different types of resources, like Databases, Front and Backend applications.

Resources that are part of the Virtual Machine life cycle

Disks: Disks are used to store operating systems, applications, or data. Each VM created on Azure has at least one OS Disk, but it can have multiple.

Terraform Script

Pre-requisites

Below is the section of Terraform that creates the pre-requisites. As I mentioned before, it is possible to use existing resources, however, you need to adapt the script to use them.

In this script, we are creating the resource group, virtual network, and subnet.

Virtual Machine

Complete Script

Below is the complete script, including provider, variables, and outputs:

Conclusion

👋 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

Mon, 01 Jan 0001 00:00:00 +0000

Don’t run out of credits on Azure!

If you are distracted and forgetful like me, you probably already forgot an Azure Virtual Machine running without need and just figured it…

Don’t run out of credits on Azure! How to shutdown Azure Virtual Machines automatically with Terraform

Photo by Tristan Gassert on Unsplash

What is Azure VM Auto-Shutdown?

Terraform resource for auto-shutdown of an Azure VM

To make it work, we will use the Terraform resource azurerm_dev_test_global_vm_shutdown_schedule. This is part of the Azure Terraform provider. The usage is quite simple, as we can see below:

The most important information required are the VM id, daily_recurrence_time, and timezone. Based on this information your VM will be shut down at the time you have defined.

Complete Terraform to create an Azure VM with auto-shutdown

To facilitate the understanding of how to integrate it in a real-life scenario, I have implemented the shutdown process in the following complete Terraform file:

Conclusion

👋 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

Mon, 01 Jan 0001 00:00:00 +0000

5 best vs code extensions for DevOps in 2022

Azure Peacock Rainbow

5 best vs code extensions for DevOps in 2022

Azure
Peacock
Rainbow

Terraform

Mon, 01 Jan 0001 00:00:00 +0000

5 VS Code tips for cloud admins to put your Productivity on the next level

Autoformat your files on save

5 VS Code tips for cloud admins to put your Productivity on the next level

Autoformat your files on save

Integrated Terminal

Debug your PowerShell scripts

Improve your git log

Live Share

Mon, 01 Jan 0001 00:00:00 +0000

5 vs code tips to put your Productivity on next level

PowerShell format on save

5 vs code tips to put your Productivity on next level

PowerShell format on save

If you are like me and like to have consistency in formating your code, this is definitely a must to have configuration.

Although vs code already have a formatter shortcut, which is alt + shift + f, you can configure to format every time you gave your file.

To configure it press F1, type settings.json and add the following section

It’s also possible to choose which changes will be formatted, the option … is particularly useful if you are working on legacy code and don’t want to change a big file at once.

This configuration applies to most part of supported languages.

Terraform auto format

The tip above works for must part of languages, but not for terraform.

To configure once again press F1, type settings.json and add the section below

It will work for tf files but not for variables.

To configure it for variable files, add this section

Git lg

Git commit/push

PowerShell debug

Mon, 01 Jan 0001 00:00:00 +0000

7 ways to create resources on Azure

Portal

7 ways to create resources on Azure

Portal

Azure CLI

Azure Powershell

Azure API’s

Bicep

Creating Infrastructure as Code for Azure with Azure Bicep step by step | by Wesley Camargo | Mar, 2022 | Medium

Terraform

Pulumi

Bonus

Other alternative tools

Open shift

Mon, 01 Jan 0001 00:00:00 +0000

8 reasons why you should consider Bicep instead of Terraform in Azure

Resource validation is not complete

8 reasons why you should consider Bicep instead of Terraform in Azure

Resource validation is not complete

Doesn’t check global unique resources

CosmosDB SQL Server throughput

Terraform doesn’t check during plan if throughput property is valid, it breaks during apply

Check if it happens also with bicep

No deployment information into Azure

You need to control the state of your resources

Wait for providers for new resources

Terraform is multi-cloud, but not like you are thinking

Different property names

Use of Variables inside modules — needs to map as local

Validate in an empty directory

terraform validate returns success in a directory with no tf files · Issue #23731 · hashicorp/terraform (github.com)

Mon, 01 Jan 0001 00:00:00 +0000

Associating an Azure DevOps service connection manually

Open App Registration in your Active Directory menu and click on New registration. Then name your service connection and click in Register

Associating an Azure DevOps service connection manually

Open App Registration in your Active Directory menu and click on New registration. Then name your service connection and click in Register

After creation, click on Certificates & secrets and New client secret

Give a name to your secret and click in add:

Copy the value generated. It will not be available for copy again. If you need it later, it will be necessary to generate a new secret.

Mon, 01 Jan 0001 00:00:00 +0000

Az Devops Pipelines Access Tokens

Understand job access tokens — Azure Pipelines | Microsoft Docs

Az Devops Pipelines Access Tokens

Understand job access tokens — Azure Pipelines | Microsoft Docs

Mon, 01 Jan 0001 00:00:00 +0000

Azure Dev Box

Announcing Microsoft Dev Box preview | Azure Blog and Updates | Microsoft Azure

Azure Dev Box

Announcing Microsoft Dev Box preview | Azure Blog and Updates | Microsoft Azure

Mon, 01 Jan 0001 00:00:00 +0000

Azure DevOps Android CICD

Tests

Azure DevOps Android CICD

Tests

Appium

Appium: Mobile App Automation Made Awesome.

Mon, 01 Jan 0001 00:00:00 +0000

Azure DevOps for beginners

Running PowerShell

Azure DevOps for beginners

Running PowerShell

Azure PowerShell & Azure CLI

Creating PowerShell Modules

Publishing PowerShell Modules to Azure Artifacts

Consuming PowerShell Modules from Azure Artifacts

Mon, 01 Jan 0001 00:00:00 +0000

Azure DevOps remote repositories in a nutshell — How to create and push your code to git

When we work on a project is fairly common that multiple people can be working and changing the same repository as you. Check on this post…

Azure DevOps remote repositories in a nutshell: How to create and push your code to git

When we work on a project is fairly common that multiple people can be working and changing the same repository as you. Check on this post how to create remote repositories on Azure DevOps, and how to link them with your local project.

Ladsgroup, CC BY-SA 4.0 , via Wikimedia Commons

Creating an Azure DevOps repository

To create the repository, it is necessary to go to the Repos area on Azure DevOps, clicking on the left menu icon. Now on the top of the screen, click on the git menu and then “New repository”:

On the popup windows, insert the name of your repository. In our case, we will use an existing repository created locally on this post, it is not interesting to add the readme or the gitignore. If you are using it for a brand new repository with no local yet, add them both of them might be a good idea 🙂.

Pushing local repository to Azure DevOps

As a decentralized version control system, git has the possibility to work locally or remotely. In this post, I showed the basic git commands and how to initialize and commit your files into local git.

To take advantage of the collaboration capacity that git has, let’s send our local repository to a remote, so other people can be able to access it.

There are two ways to work with a remote repository, let's explore them:

Pushing an existing repository to Azure DevOps

As mentioned above, we will use an already created local repository, so instead of cloning, we will add a new remote to this repository. Below the command will add the remote repo and push your commits to that.

Azure DevOps make it easy and create that for you, you can simply copy the command generated and run it on your terminal:

We can check the remote repositories with the command git remote -v :

Cloning the remote repository locally

It is also possible to clone the remote existing repo to your local computer. The command git clone <your repository url> does that, and it is very straightforward. In our example, we are cloning the same repository that we pushed in the step above:

Key takeaways

Although one of the advantages of git is being a decentralized version control system, knowing how to work with remote repositories is crucial for anyone that uses git. It’s an easy way to work collaboratively and keep the continuous integration of your applications.

Mon, 01 Jan 0001 00:00:00 +0000

Azure DevOps to GitHub Journey

General comparison

Azure DevOps to GitHub Journey

General comparison

Functionalities

New versions

Price

Mon, 01 Jan 0001 00:00:00 +0000

Azure Key Vault for Beginners —5 ways to create an Azure Key Vault in less than 1 minute

1- The easy, but not recommended way — Create an Azure Key Vault by Portal

Azure Key Vault for Beginners —5 ways to create an Azure Key Vault in less than 1 minute

1- The easy, but not recommended way — Create an Azure Key Vault by Portal

2- The acceptable way — Using Scripts

Azure CLI

Azure PowerShell

How to create an Azure Key Vault with Bicep

How to create an Azure Key Vault with Terraform

Mon, 01 Jan 0001 00:00:00 +0000

Azure Landing Zone Fundamentals: A Guide to Understanding the Building Blocks of Azure

With the cloud infrastructure landscape rapidly changing, the implementation of Landing Zones is becoming a crucial aspect of cloud…

Azure Landing Zone Fundamentals: A Guide to Understanding the Building Blocks of Azure

Photo by Pascal Meier on Unsplash

With the cloud infrastructure landscape rapidly changing, the implementation of Landing Zones is becoming a crucial aspect of cloud infrastructure and increasingly important for organizations looking to maximize their cloud investments. In this post, we will understand the basics of Landing Zones in Azure, what they are, their purpose, and the significance they hold for modern businesses.

Introduction to Azure Landing Zones and their importance for cloud infrastructure

Platform Landing Zones

When a company decides to start using a new cloud platform, there are many aspects that need to be considered in the earlier stages. If not enough attention is paid to them, they might be a stone in the shoe in the future, bringing numerous problems and risks related to Security, Governance, Costs, and Scalability.

To solve these risks, mostly if not Cloud Providers have guides on how to prepare the fundamental resources that all future workloads and applications will run on top of, for instance, Networks, Users and Identities, Governance, Management, and Security.

These fundamental resources are then put in place, so we can “Land” our applications on top of it, giving the name “Platform Landing Zone”, enabling modernization and innovation at the enterprise scale supporting all necessary resources to keep client applications running.

Platform Landing Zone — Microsoft Learn

Application Landing Zones

Setting up governance and compliance with Azure Landing Zones

Implementing security and network isolation with Azure Landing Zones

Automating deployment and scaling with Azure Landing Zones

Best practices for using Azure Landing Zones in your cloud deployment

Real-world examples of businesses successfully using Azure Landing Zones

Conclusion and next steps for optimizing your Azure Landing Zone deployment and realizing its benefits.

Mon, 01 Jan 0001 00:00:00 +0000

Config development environment

Windows Terminal Powerline Setup | Microsoft Docs

Config development environment

Windows Terminal Powerline Setup | Microsoft Docs

Import-Module posh-git

Import-Module oh-my-posh

Set-PoshPrompt -Theme paradox -> replace by Set-Theme paradox

Windows Terminal installation | Microsoft Docs

Mon, 01 Jan 0001 00:00:00 +0000

Configuring AKS

Terminology

Configuring AKS

Terminology

Container - is a package with everything necessary to run an application. the smaller unit in the AKS environment,
Pod — is an instance of an application. It can have one or more containers
Deployment — it has one or more identical pods
Nodes— VMs running containerized applications
Pool — Groups of nodes with the same configuration

AKS Cluster architecture

AKS Clusters

Nodes are VMs running containerized applications, and are divided into two types in AKS:

Azure-managed nodes — This is a managed node abstracted by Azure, providing the core Kubernetes services and orchestration of applications.
Customer-managed nodes — These clusters are where the customer applications run, being administered by him.

AKS Nodes architecture

Nodes are virtual machines that run applications.

Explore the AKS cluster and node architecture — Training | Microsoft Learn

AKS Networking

To enable communication between applications, Kubernetes abstracts a vNet layer. The nodes are connected to a vNet a

Mon, 01 Jan 0001 00:00:00 +0000

Consuming variables in Azure DevOps YAML Templates

Variable scopes

Consuming variables in Azure DevOps YAML Templates

Variable scopes

Reading variables in Azure DevOps YAML Templates

Macro syntax

Template expression syntax

Runtime expression syntax

Environment variables

Mon, 01 Jan 0001 00:00:00 +0000

containers without docker desktop wsl2 windows 11

Install Docker in WSL 2 without Docker Desktop — Nick Janetakis

containers without docker desktop wsl2 windows 11

Install Docker in WSL 2 without Docker Desktop — Nick Janetakis

curl: (6) Could not resolve host: get.docker.com

sudo nano /etc/resolv.conf

# nameserver 172.26.144.1
nameserver 8.8.8.8

Signatures couldn’t be verified:

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

Install Docker Engine on Ubuntu | Docker Documentation

Check if it’s running:

service docker status

 sudo service docker start

sudo update-alternatives --config iptables

Choose option “1”

Dotnet app

Docker images for ASP.NET Core | Microsoft Learn

Install .net

Install .NET on Ubuntu — .NET | Microsoft Learn

Install Az cli on wsl

Install the Azure CLI on Linux | Microsoft Learn

Push image

Push & pull container image — Azure Container Registry | Microsoft Learn

Mon, 01 Jan 0001 00:00:00 +0000

Creating a CI/CD pipeline with GitHub Actions

In this post I will show how to create an application .net core, version on GitHub, create a workflow using Action and deploy on Azure

Creating a CI/CD pipeline with GitHub Actions

In this post I will show how to create an application .net core, version on GitHub, create a workflow using Action and deploy on Azure

To follow this post, you will need:

Visual Studio Code — You can download here
DotNet Core SDK — You can download here
A GitHub account
An Azure account

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

All command used in this post are bellow, I will explain all this

Creating an application

After all pré reqs are ok, open your VS Code, click in Open folder and select an empty folder to create the project:

On the superior menu click on Terminal -> Terminal or press ctrol + ‘, so a new terminal will open in

dotnet --version

No 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 webapp

Esse 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 run

Isso 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

dotnet new gitignore

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

git initgit 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:

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

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!

Mon, 01 Jan 0001 00:00:00 +0000

Creating an Azure Web App with Azure DevOps Release Engine

Mon, 01 Jan 0001 00:00:00 +0000

Creating and configuring storage accounts on Azure

Storage Account Concepts

Creating and configuring storage accounts on Azure

Storage Account Concepts

How to create a Storage Account

Creating a Storage Account with Azure CLI

Creating a Storage Account with Azure PowerShell

Creating a Storage Account with Azure Bicep 💪

To execute the bicep file, it is necessary to use either Azure PowerShell or Azure CLI. In this example, we are using Azure CLI and creating the Resource Group with it as well.

Deleting a Storage Account

Deleting a Storage Account with Azure CLI

Deleting a Storage Account with Azure PowerShell

Update

Azure CLI

Azure PowerShell

Get Storage Information

Mon, 01 Jan 0001 00:00:00 +0000

Creating Azure SQL Database with Bicep and Azure DevOps YAML Pipelines

Mon, 01 Jan 0001 00:00:00 +0000

Databricks Environment

sudo apt update

Databricks Environment

sudo apt update

sudo apt install python3-pip

pip3 — version

sudo apt-get install -y make build-essential libssl-dev zlib1g-dev libbz2-dev libreadline-dev libsqlite3-dev wget curl llvm libncurses5-dev libncursesw5-dev xz-utils tk-dev libffi-dev liblzma-dev python-openssl

sudo apt install python3

curl https://pyenv.run | bash

update the file ~/.bashrc

export PATH=”/home/wesley/.pyenv/bin:$PATH”
eval “$(pyenv init -)”
eval “$(pyenv virtualenv-init -)”

pyenv --help

pyenv install 3.7.0

pipenv install toolz --python 3.8.5

if has error related to ModuleNotFoundError: No module named ‘_ctypes’:

sudo apt-get install libffi-dev
sudo apt remove python3
sudo apt install python3

Managing Multiple Python Versions With pyenv — Real Python

Creating virtual environments with Pyenv — Rob Allen’s DevNotes (akrabat.com)

pip install -U pytest

Mon, 01 Jan 0001 00:00:00 +0000

DataOps Automation — Creating an Azure Databriks workspace with Bicep and Azure DevOps

Preparing Bicep Environment

DataOps Automation — Creating an Azure Databriks workspace with Bicep and Azure DevOps

Preparing Bicep Environment

Mon, 01 Jan 0001 00:00:00 +0000

DataOps on Azure - Authorizing an Azure Data Factory to manage a Databricks with Managed Identities…

In big data architectures, it’s a common need to have an orchestrator managing other resources. On Azure, this tool is the Azure Data…

DataOps on Azure - Authorizing an Azure Data Factory to manage a Databricks with Managed Identities and Az DevOps

In big data architectures, it’s a common need to have an orchestrator managing other resources. On Azure, this tool is the Azure Data Factory and we can handle many resources like SQL Servers, Storage Accounts, Databricks, among others. A prerequisite for this orchestration is that ADF has permissions on the resource that it must control, and this is the motivation for using Managed Identities: granting these permissions simply and quickly.

What´s a Managed Identity?
A Managed Identity is an easy way to set up your Azure Environment in scenarios that you have resources consuming other resources. Below we can see common situations that you can use this:

If you want to know more about how Managed Identities works, you can find it here Managed identities for Azure resources | Microsoft Docs =)

Assign a managed identity access to a resource using Azure CLI — Azure AD | Microsoft Docs

Troubleshoot Azure RBAC | Microsoft Docs

Azure built-in roles — Azure RBAC | Microsoft Docs

Mon, 01 Jan 0001 00:00:00 +0000

Delivery as Code with Azure DevOps release engine

Delivery as Code is the concept of have all necessary configurations of your delivery such as environments, resources to be deployed…

Delivery as Code with Azure DevOps release engine

Delivery as Code is the concept of have all necessary configurations of your delivery such as environments, resources to be deployed, different variables for your environments and so on defined in a file, which can be kept under source control.

Mon, 01 Jan 0001 00:00:00 +0000

Deploy Azure landing zones

Deploy Azure landing zones — Azure Architecture Center | Microsoft Learn

Deploy Azure landing zones

Deploy Azure landing zones — Azure Architecture Center | Microsoft Learn

Azure landing zones — Bicep modules design considerations — Azure Architecture Center | Microsoft Learn

Mon, 01 Jan 0001 00:00:00 +0000

Deploying SQL Server with Azure DevOps YAML pipelines

Mon, 01 Jan 0001 00:00:00 +0000

DevOps for beginners — Running PowerShell on Azure DevOps

How to run PowerShell Inline on Azure DevOps

DevOps for beginners — Running PowerShell on Azure DevOps

How to run PowerShell Inline on Azure DevOps

Using Azure DevOps PowerShell task

azure-pipelines-tasks/Tasks/AzurePowerShellV5 at master · microsoft/azure-pipelines-tasks (github.com)

Using Azure DevOps PowerShell Shortcuts

How to run PowerShell Scripts on Azure DevOps

How to read environment variables on Azure DevOps with PowerShell

Creating Outputs

Mon, 01 Jan 0001 00:00:00 +0000

Force redeployment on terraform

Forcing Re-creation of Resources — Terraform CLI | Terraform | HashiCorp Developer

Force redeployment on terraform

Forcing Re-creation of Resources — Terraform CLI | Terraform | HashiCorp Developer

terraform apply -replace=”azurerm_virtual_machine_extension.iis”

Mon, 01 Jan 0001 00:00:00 +0000

From Terraform to Azure Bicep:

CLI Tools

From Terraform to Azure Bicep:

CLI Tools

Authentication to Azure

Deployment scopes (resource groups, subscriptions)

Modularity and Reusability

State Management

Provider Support

Linkedin feedback

- Bicep is essentially an ARM transpiler to a nicer (more HCL esque) language, therefore has all the advantages and disadvantages of ARM.
- Terraform keeps state where Bicep doesn’t, this has varied consequences.
- Bicep will gain newer features in Azure faster than Terraform due to it being so closely related to ARM which always gets new features first.
- Terraform will allow you to use other providers and hook into other systems where Bicep will make this difficult.
- Terraform can do destroy and plan where this functionality is either missing or poorly implemented in ARM and thus Bicep.

Modularity and Reusability

Comparison of the modularity and reusability features of Terraform and Azure Bicep.
Explanation of the similarities and differences between the two tools’ approaches to modularity and reusability.
Discussion of the benefits of Azure Bicep’s more tightly integrated module system and how it differs from Terraform’s ecosystem of modules.

State Management

Comparison of how Terraform and Azure Bicep handle state management.
Explanation of the similarities and differences between the two tools’ approaches to state management.
Discussion of the benefits of Azure Bicep’s use of ARM templates for state management and how it differs from Terraform’s state file.

Provider Support

Comparison of the provider support of Terraform and Azure Bicep.
Explanation of the similarities and differences between the two tools’ approaches to provider support.
Discussion of the benefits of Azure Bicep’s deep integration with Azure and how it differs from Terraform’s support for a wide range of cloud providers.

Getting Started with Azure Bicep

Practical advice and tips for getting started with Azure Bicep, including installation and configuration.
Comparison of the steps required to create a simple infrastructure with Terraform and Azure Bicep.
Discussion of the benefits and challenges of switching from Terraform to Azure Bicep.

Conclusion

Recap of the similarities and differences between Terraform and Azure Bicep.
Final thoughts on the benefits of using Azure Bicep for cloud infrastructure management.
Call to action for readers to give Azure Bicep a try.

Mon, 01 Jan 0001 00:00:00 +0000

From Terraform to Azure Bicep: What You Need to Know about Provisioning lifecycle

Comparing Terraform and Bicep | Microsoft Learn

From Terraform to Azure Bicep: What You Need to Know about
Provisioning lifecycle

Comparing Terraform and Bicep | Microsoft Learn

Bicep language for deploying Azure resources — Azure Resource Manager | Microsoft Learn

Mon, 01 Jan 0001 00:00:00 +0000

From Terraform to Azure Bicep: What you need to know about CLI

Hey there! Welcome back to our blog series “From Terraform to Azure Bicep.” In my previous post, we discussed the differences in the main…

From Terraform to Azure Bicep: What you need to know about CLI

Hey there! Welcome back to our blog series “From Terraform to Azure Bicep.” In my previous post, we discussed the differences in the main components of the file structure. Now, it’s time to compare Terraform and Azure/Bicep CLI tools for infrastructure management. In this blog post, we will dive deep into the similarities and differences between them, and help you understand how to use them to manage your infrastructure. So let’s get started!

Both tools support a wide range of operating systems, including Windows, macOS, and Linux. The installation and configuration are relatively simple and can be done using tools such as Chocolatey and apt-get, as we will see below. let’s take a closer look at each tool:

What is Bicep CLI?

How does Bicep CLI works?

Bicep CLI is part of Azure CLI, which is a tool for managing Azure resources only. One of the great things about Azure CLI is its flexibility and ease of use. It allows the use of declarative and imperative approaches when interacting with resources, although, for declarative, it is necessary to combine its use with Azure Bicep. Azure CLI and Bicep are easy to install using tools like Chocolatey and apt-get.

What is Terraform CLI?

Terraform CLI allows the declarative approach through terraform files, not being possible to interact with cloud resources directly. While it may have fewer capabilities than Azure CLI, Terraform is extremely flexible and supports a wide range of cloud providers, including Azure, AWS, GCP, and even VMWare. Like Azure CLI, Terraform CLI is easy to install using tools like Chocolatey and apt-get.

How to install and configure Azure Bicep 💪and Azure CLI

How to install Azure CLI locally on Windows using Chocolatey

The installation script below does the following:

Checks if Chocolatey is installed, and install it if it’s not already installed.
Installs the Azure CLI package using Chocolatey.
Verifies the installation by running az --version.

To use this script, simply copy and paste it into a file with a .ps1 extension (e.g. install-azure-cli.ps1), open a PowerShell prompt as administrator, navigate to the directory where the script is saved, and run it using the command .\install-azure-cli.ps1. Note that you may need to modify your execution policy to run PowerShell scripts - you can do this by running Set-ExecutionPolicy RemoteSigned or Set-ExecutionPolicy Unrestricted from an elevated PowerShell prompt.

How to install Azure CLI on Linux using apt-get

The installation script using apt-get has a few more steps than using choco, and does the following:

Updates the package list
Installs the necessary dependencies
Downloads and adds the Microsoft signing key to the trusted keyring
Adds the Azure CLI software repository to the sources list
Updates the package list again, and installs the Azure CLI
Verifies the installation by running az --version

To use this script, simply copy and paste it into a file, save the file with a .sh extension (e.g. install-azure-cli.sh), make it executable using chmod +x install-azure-cli.sh, and then run it with ./install-azure-cli.sh.

How to install and configure Terraform CLI

How to install Terraform CLI on Windows using Chocolatey

Installing Terraform CLI with Chocolatey is simple and can be done with the script below:

To run the script check the Azure CLI session above😉.

How to install Terraform CLI on Linux using apt-get

The installation of Terraform CLI on Linux is simple as the Azure CLI. Below we can see the script for that. The instructions to run this script are also the same a for Azure CLI.

Overview of Azure CLI

Explanation of Azure CLI and its capabilities
Benefits and drawbacks of using Azure CLI
Examples of Azure CLI commands and how they are used

Overview of Terraform CLI

Explanation of Terraform CLI and its capabilities
Benefits and drawbacks of using Terraform CLI
Examples of Terraform CLI commands and how they are used

Comparison of Terraform CLI and Azure CLI

Comparison of syntax and language used by both tools
Comparison of how they handle state management and version control
Comparison of available resources and integrations
Explanation of which tool may be more suitable for certain scenarios

Conclusion

Recap of main points and differences between Terraform CLI and Azure CLI
Final thoughts on which tool may be best for different use cases.

Mon, 01 Jan 0001 00:00:00 +0000

Git & DevOps

Mon, 01 Jan 0001 00:00:00 +0000

GitHub CodeSpaces

GitHub Codespaces overview — GitHub Docs

GitHub CodeSpaces

GitHub Codespaces overview — GitHub Docs

Mon, 01 Jan 0001 00:00:00 +0000

Helm Charts Sheet Cheat

Install Helm on Windows: choco install kubernetes-helm

Helm Charts Sheet Cheat

Install Helm on Windows:
choco install kubernetes-helm

Helm Repositories

helm repo add <repo-name> <url> # Add a repository from the internet:
helm repo list

Install Kubectl

choco install kubernetes-cli
choco install kubelogin

AKS

-A means all namespaces

# Get everything in all Namespaces (-A)
kubectl get all -A

# Get namespaces
 kubectl get namespace
 kubectl get ns

# Get deployments
kubectl get deployment

# Delete deployment
kubectl delete deployment <deployment name> -n <namespace>

# Create certificate secret
kubectl create secret tls <secret name> --cert=<path to crt certificate> --key=<path to certificate key> -n <namespace>

Mon, 01 Jan 0001 00:00:00 +0000

How to achieve DevOps in your company

Goals

How to achieve DevOps in your company

Goals

Discover DevOps — Learn | Microsoft Docs

What is DevOps? DevOps explained | Microsoft Azure

Planning

Integration

Delivery

Operations

DevOps Goals

It is common that people think about DevOps as automated deployment. Indeed, one of the goals in DevOps is to have as many automated processes as possible, but DevOps goes ways beyond that.

The main objective of DevOps is to enable the ability to deliver value through the union of People, Processes and Tools with quality and speed.

To achieve this goal, just automation is not enough. You need to change processes and people's mindsets. This is very related to Agile and Lean mindsets, and in my point of view, DevOps complements them. If a team has a Definition of Done that all tests must pass in a QA environment, it does not deliver real value to his company or client. The real value comes when the code is working in the Production environment.

So how to build a DevOps culture in your organization?

How to evolve DevOps as a capability for my teams?

In my experiences working with many clients, the most successful results come from the cases that we treat DevOps as a capability to be evolved inside the teams, than those that consider DevOps a person inside the team responsible for releases or automation.

By definition, DevOps is the union of Development and Operations. So have just one person to create this bridge will not work in a long term. The “DevOps resource” will become a carrier pigeon, and both, Development and Operations teams will not evolve the practices and achieve the integration desired.

Start DevOps as resources

When a team has someone with DevOps expertise, the tendency is that all activities related to releases, be it deployment automation or even releases that are done manually will be done or coordinated by this DevOps person. On one hand, this is very nice to understand the project's big picture, identify the best processes that are candidates to automation watching which ones are more painful and susceptible to errors, but the dark side of it is that this person will become a bottleneck soon or later.

Another negative point is the tendency to work isolated. Each team creates your own deployment solutions or processes, and it means that you can spend too much time on one solution, and next week another team can also spend too much time on a solution for the same problem.

Moving to a DevOps enabler strategy

The ace in the sleeve is to have DevOps enablers and not DevOps resources inside the team. It looks similar but there is a big difference there.

Implementation Stages

To achieve DevOps, you need to have in place a series of practices that are very related to Agile development and Lean. It means that you need to think of DevOps as culture much more than automated deployments.

Exploration — Understanding the current scenario

When you are start

Manual activities

Advocating — Promoting DevOps practices into the teams

Automation

Supporting — Support teams to be autonomous

Pessoas

Processos

Ferramentas

Mon, 01 Jan 0001 00:00:00 +0000

How to configure environments on Azure DevOps YAML Pipelines

Mon, 01 Jan 0001 00:00:00 +0000

How to configure environments with Azure DevOps YAML Pipelines

What are environments on Azure DevOps?

How to configure environments with Azure DevOps YAML Pipelines

What are environments on Azure DevOps?

Creating an environment on Azure DevOps

Approvals and Checks

Referencing an environment in Azure DevOps YAML Pipeline

Giving permission to Azure DevOps Pipelines into environments

Mon, 01 Jan 0001 00:00:00 +0000

How to create an Azure function

Mon, 01 Jan 0001 00:00:00 +0000

How to delete all resources with specific tag Azure CLI PowerShell

az group list --query "[?tags.automationToolkit == 'true' && tags.example == 'true'].name" -o tsv | ForEach-Object { Write-Host "Removing resource $_"; az group delete --no-wait --yes -n $_ }

Mon, 01 Jan 0001 00:00:00 +0000

How to delete unused resources in Azure Data Factory during deployment

Continuous integration and delivery pre- and post-deployment scripts — Azure Data Factory | Microsoft Docs

How to delete unused resources in Azure Data Factory during deployment

Continuous integration and delivery pre- and post-deployment scripts — Azure Data Factory | Microsoft Docs

Mon, 01 Jan 0001 00:00:00 +0000

How to enable Azure Load Balancer High Availability Ports with Terraform

Mon, 01 Jan 0001 00:00:00 +0000

How to extend an Azure DevOps YAML Pipeline Template from different repository

Mon, 01 Jan 0001 00:00:00 +0000

How to install and setup Git

How to install git on Windows

How to install and setup Git

How to install git on Windows

Git — Installing Git (git-scm.com)

How to install git on Windows with winget

In Windows 11 and newer versions of Windows 10 Winget is already installed, if you are running an older version, you can install it from App Installer — Microsoft Store Apps.

After that, you just need to run the command below:

It might be necessary close and reopen the terminal session

How to install git on Windows using choco

How to setup git credentials

How to setup git username and email

How to setup vscode as the default git editor

Installing vscode

How to create an alias on git

Linked post: How to create an alias for gitlog

Mon, 01 Jan 0001 00:00:00 +0000

How to monitor Azure Resources with SCOM

Mon, 01 Jan 0001 00:00:00 +0000

How to use Azure DevOps YAML Pipelines Templates

The easiest way to take over control of your deployments

How to use Azure DevOps YAML Pipelines Templates

The easiest way to take over control of your deployments

You can be a Developer a DevOps Engineer or an Operations guy, but if you need to maintain several applications in production certainly you faced a lot of problems. I have good news for you! There is an easy way to take over the control of your CI/CD process, and templates are the answer for that…

Pipeline as Code

What is “as Code” mean?

In the last years the concept of “As Code” is being adopted for all sorts of components. The most common scenario to use it is with Infrastructure as Code aka IaC, but if you are tuned in to the best practices related to the technology world maybe you also heard about Database as Code, Configuration as Code, and why not Pipeline as Code as well?

As code means that you keep all configurations under a Source Control, and you can apply the same practices as in a traditional application, like versions, tags, and tests for example.

Prerequisites for Pipeline as Code

Version Control System - To start you need to choose a Version Control System, most probably a git-based one, like GitHub, Azure Repos, or GitLab.

Continuous Deployment Tool - You will also need to choose a CI/CD tool with support to Pipeline as Code. The most known tools for that are GitHub Actions and Azure DevOps YAML Pipelines. In this post, I will use Azure DevOps YAML Pipeline to show how to use the benefits of the Pipeline as Code.

Azure DevOps YAML Pipelines Templates

YAML Templates are a smart way to create your pipelines. The most advantageous characteristics are:

It allows to break down the pipelines into small pieces.
You can call in your main pipelines, but it also supports nested insertions.
Control of what is allowed in the pipeline.

best practices in our deployment pipelines.

Single Responsibility Principle

As you can build small segments and insert them into a main pipeline, it allows the reusability of logic.

Dependency Inversion

Declarative instead of imperative scripts

Inject Templates

Extend Templates

Mon, 01 Jan 0001 00:00:00 +0000

Incrementing versions with GitVersion

choco install GitVersion.Portable

Mon, 01 Jan 0001 00:00:00 +0000

Installing ArgoCD into AKS Cluster

Preparing Helm chart

Installing ArgoCD into AKS Cluster

Preparing Helm chart

How to get a Helm chart from Bitnami repository

Let’s add Bitnami repository and download the ArgoCD Helm chart :

mkdir ~/argo-cd
cd ~/argo-cd

helm repo add argo https://argoproj.github.io/argo-helm
helm pull argo/argo-cd

Create namespace on AKS

# Create Kubernetes Namespace
kubectl create ns argo-cd

# Add Argo CD repository
helm repo add argo https://argoproj.github.io/argo-helm

helm install argocd argo/argo-cd -n argo-cd

Override configurations:

Get all configurations:

helm show values argo/argo-cd > values.yml

Create an yaml file and fill according to the documentation on argo-helm/charts/argo-cd at main · argoproj/argo-helm (github.com)

server:
 service:
 type: NodePort
 server.service.nodePortHttp: 30080
 server.service.nodePortHttps: 30443

Run the install command passing the file as parameter

helm install argocd argo/argo-cd -n argo-cd -f values-ingress.yaml

Check the result:

NGINX

ingress-nginx/charts/ingress-nginx at main · kubernetes/ingress-nginx (github.com)

# Create K8s workspace
kubectl create ns ingress-nginx

# Nginx repo
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx

# Install Nginx chart
helm install ingress-nginx ingress-nginx/ingress-nginx -n ingress-nginx

kubectl -n ingress-nginx get pods

# Show ingress service
kubectl -n ingress-nginx get svc

How to add a Helm chart to Azure Container Registry

Lets first define a variable with the name of our ACR, do not add the .azurecr.io , only the name:

ACR_NAME=<container registry name>

To authenticate to Azure Container Registry using your EntraId we need first to login using az login and get the password using the command below:

USER_NAME=”00000000–0000–0000–0000–000000000000"
PASSWORD=$(az acr login — name $ACR_NAME — expose-token — output tsv — query accessToken)

Note that 00000000–0000–0000–0000–000000000000 is not a placeholder and must be kept.

Now it’s time to run the command to authenticate:

helm registry login $ACR_NAME.azurecr.io \
 --username $USER_NAME \
 --password $PASSWORD

And finally, push the chart to ACR:

helm push argo-cd-5.9.2.tgz oci://$ACR_NAME.azurecr.io/helm

Mon, 01 Jan 0001 00:00:00 +0000

Introducing Azure Load Testing: Optimize app performance at scale

Introducing Azure Load Testing: Optimize app performance at scale | Azure Blog and Updates | Microsoft Azure

Introducing Azure Load Testing: Optimize app performance at scale

Introducing Azure Load Testing: Optimize app performance at scale | Azure Blog and Updates | Microsoft Azure

Mon, 01 Jan 0001 00:00:00 +0000

Managed Identities

The problem with connection strings

Managed Identities

The problem with connection strings

To communicate with resources in Azure your application might need to authenticate within Azure resources. An example is an App Service running a dotnet application that needs to connect to your Azure SQL Server.

Before the cloud, the most common way to access a database was through connection strings. In this approach usually, the applications have a configuration file containing the application settings necessary for the application run, and the connection string is stored there, among other configurations.

This process sometimes lacks security measures and the secret is stored in plain text in the configuration files, sometimes being under source control. Anyone with access to the environment or repositories has access to the connection string and can potentially use it for obscure objectives.

In more advanced cases, this process can be done through a CI/CD process which can retrieve automatically the connection string and store it in a vault, such as Azure Key Vault. But even with this process, as the connection string should be stored, there is always a risk that someone can find it.

This approach is still used in many resources on Azure such as Storage Accounts and Azure SQL. So how can we communicate with our resources in a more secure way?

Understanding Azure Active Directory Identities

Creating an Identity for the application

A quite elegant way to solve the connection string problem is creating an Identity for our application or resource that needs to communicate with other resources in Azure.

In this approach, we register the application in the Azure Active Directory tenant, allowing the integration between the application and Azure AD with a behavior similar to a service account.

Traditionally this communication is done through connection strings. This approach works fine but also has a security risk in that it can be leaked and also expires, being necessary a rotation process to avoid downtime of your application.

Where to keep the connection string?
How to ensure that it is secured?
How to rotate them to avoid risks?
Who will handle the creation process and maintenance of the connection strings?

What are Service Principals?

What are Managed Identities?

Mon, 01 Jan 0001 00:00:00 +0000

Managing Storage Keys with KeyVault

Manage storage account keys with Azure Key Vault and the Azure CLI | Microsoft Docs

Managing Storage Keys with KeyVault

Manage storage account keys with Azure Key Vault and the Azure CLI | Microsoft Docs

Use Azure CLI to create a user delegation SAS for a container or blob — Azure Storage | Microsoft Docs

az keyvault storage sas-definition | Microsoft Docs

az storage container | Microsoft Docs

Mon, 01 Jan 0001 00:00:00 +0000

Mastering Azure Bicep and the Azure Bicep Registry: A Beginner’s Guide

Mon, 01 Jan 0001 00:00:00 +0000

PowerShell debug

Mon, 01 Jan 0001 00:00:00 +0000

Replacing values on Azure Data Factory in CI/CD pipelines

Replace a development value with a production value is very simple on the Azure Data Factory. If you have different endpoints for your…

Replacing values on Azure Data Factory in CI/CD pipelines

Replace a development value with a production value is very simple on the Azure Data Factory. If you have different endpoints for your components, this is one of the basic DevOps processes that you need to take care of, and using the ARM Templates deployment can make it much more simple.

Photo by Goh Rhy Yan on Unsplash

Azure Data Factory Deployment

There are some strategies to deploy Azure Data Factory. The method demonstrated in this post is applicable for the strategies that deploy the ARM Templates generated by Azure Data Factory Publish or for the new flow that uses an NPM task to generate the ARM artifacts.

Deployment with new Azure Data Factory flow — Image from Microsoft Docs

If you are not familiar with the new flow yet, you can check it on this post, in which I am explaining the differences between the old flow and the new one, and also showing step by step the process to create a YAML deployment using it.

ARM Parameter configuration

ARM Template parameter definition

Overriding parameters

Key Vault and App Configuration

Mon, 01 Jan 0001 00:00:00 +0000

Run databricks notebook with Azure DevOps

Databricks authentication methods

Run databricks notebook with Azure DevOps

Databricks authentication methods

Azure Active Directory Token from Service Principal Name

Databricks Personal Access Token

Environment Variables

Authenticate to Databricks with Azure DevOps

Using Azure DevOps Service Principal Name

Running databricks notebooks from Azure DevOps pipeline

Key Takeaways

Mon, 01 Jan 0001 00:00:00 +0000

Running Powershell on Azure DevOps

Mon, 01 Jan 0001 00:00:00 +0000

Sending a Release Notes report from Azure DevOps by mail

When we finish a release it’s interesting to communicate to the responsible team if everything occurs fine(or not!) and what new Features…

Sending a Release Notes report from Azure DevOps by mail

When we finish a release it’s interesting to communicate to the responsible team if everything occurs fine(or not!) and what new Features or corrections were deployed. I’ll show the simple pathway to do this.

We’ll start with our Azure DevOps account creating a work item.

Mon, 01 Jan 0001 00:00:00 +0000

Simplifying Creativity: Deploying Generative AI through Azure OpenAI

If you are a fan of Marvel’s comics, you should remember Jarvis, the Iron Man assistant. What if I tell you that Generative AI can help you…

Simplifying Creativity: Deploying Generative AI through Azure OpenAI

If you are a fan of Marvel’s comics, you should remember Jarvis, the Iron Man assistant. What if I tell you that Generative AI can help you in the same way, creating stuff that’ll make you go “Wow, did a robot do this?” In this blog post series, I will show you how to make an Azure Open AI deployment, and build your own copilot using cutting-edge generative AI models created by OpenAI!🚀🤖

Photo by Gerard Siderius on Unsplash

Introduction to Generative AI

What is Generative AI?
The Impact of Generative AI on Industries
Azure OpenAI: Bridging the Gap Between AI and Creativity

Preparing for Azure OpenAI Deployment

Setting Up Your Azure Account for Azure OpenAI

To get started with Azure OpenAI, you must have an Azure Account. If you still don’t have it, you can create an account for free here.
As Azure OpenAI is still under development, you need to apply for access on this page. After it’s approved, you will be able to create an Azure OpenAI resource.

Creating a New Azure OpenAI Resource

Navigating to the Azure OpenAI Service

Configuring Your OpenAI Resource

Choosing the Right Configuration Options
Understanding Pricing and Performance Tiers
Finalizing the Setup and Reviewing Settings (Placeholder for Screenshot)

Deploying Azure OpenAI

Accessing Deployment Settings in the Azure Portal
Deploying Your Generative AI Model with Azure OpenAI
Successful Deployment Confirmation (Placeholder for Screenshot)

Post-Deployment Steps

Verifying Deployment and Resource Health
Setting Up API Keys for Secure Access
Testing Your First Generative AI Request (Placeholder for Screenshot)

Mon, 01 Jan 0001 00:00:00 +0000

SSH on Azure DevOps

ssh-keygen -t rsa -b 4096

SSH on Azure DevOps

ssh-keygen -t rsa -b 4096

cat /home/wesley/.ssh/id_rsa.pub

upload id_rsa to variable group

Mon, 01 Jan 0001 00:00:00 +0000

Stop! Not all teams are ready for Trunk Based development

In the past years, I have been working with teams around the world, and I can say: every team is different and has different maturity…

Stop! Not all teams are ready for Trunk Based development

In the past years, I have been working with teams around the world, and I can say: every team is different and has different maturity levels, and if you try to push the same strategy to all of the team, this is a recipe for disaster.

5 things you need to know before deciding your branch strategy

1- What is the DevOps maturity level of your team?

Does your company already have DevOps practices?

Version control
Continuous Integration
Continuous Deployment
Continous Delivery

How to measure the DevOps maturity of your team?

2- How your environment looks like?

Which resources are you using?

Are these cloud resources?
How are they provisioned?
Is there automation?

Does your team have a development environment?

How automated is your environment?

3- What is your release strategy?

Feature flags

4- Is your process well structured or under development?

Mon, 01 Jan 0001 00:00:00 +0000

Sua empresa tem o fluxo de valor mapeado?

Já parou pra pensar como os lanches do McDonald’s ficam prontos tão rapidamente?

Sua empresa tem o fluxo de valor mapeado?

Já parou pra pensar como os lanches do McDonald’s ficam prontos tão rapidamente?

Cada etapa na produção dos lanches é realizada em um local especialmente projetado e por uma pessoa especialmente treinada para essa etapa. E após cada etapa ser concluída, seu lanche vai para a seguinte, segundo uma ordem correta até seu lanche chegar em suas mãos e você poder saboreá-lo.

Cada uma dessas etapas precisa ser executada em uma ordem para ao final o lanche sair de acordo com a foto. Eu sei que a maioria das vezes os lanches não são iguais as fotos, mas a ordem dos ingredientes precisa ser seguida, já pensou o bacon embaixo da primeira fatia de pão e o hambúrguer em cima da segunda? ;p

Isso pode ser chamado de fluxo de valor e sua definição de acordo com Lean é:

“A sequência de atividades em uma organização para entregar um pedido a um cliente.”

Isso significa que todas as etapas entre o pedido de um cliente até sua entega, seja de um hambúrguer, ou de um sistema, passam por etapas de um processo que pode estar em um estágio mais basico ou mais avançado. E isso pode definir o grau de maturidade do seu processo!

Focar no essencial

Algumas cenas do post são do filme “Fome de Poder”, aliás, recomendo que assistam, que retrata a história do McDonalds’s. No filme conhecemos como a ideia inovadora criada pelos irmãos McDonalds’s de separar e otimizar os processos de fabricação dos hambúrgueres na lanchonete mais famosa do mundo.

A grande sacada é otimizar o processo através da eliminação de etapas inúteis e manter apenas o essencial, o necessário para produzir os hambúrgueres o mais rápido possível.

Identificar gargalos

Com o fluxo em que

Mon, 01 Jan 0001 00:00:00 +0000

Terraform deploy in multiple subscriptions

terraform-azurerm-vnet-peering/main.tf.ci at master · claranet/terraform-azurerm-vnet-peering (github.com)

Terraform deploy in multiple subscriptions

terraform-azurerm-vnet-peering/main.tf.ci at master · claranet/terraform-azurerm-vnet-peering (github.com)

Mon, 01 Jan 0001 00:00:00 +0000

Testing bicep with PSRule

Testing Bicep Code Using PSRule in Azure Pipeline — Managing Cloud and Datacenter by Tao Yang (tyang.org)

Testing bicep with PSRule

Testing Bicep Code Using PSRule in Azure Pipeline — Managing Cloud and Datacenter by Tao Yang (tyang.org)

Test your resources after deployment — Learn | Microsoft Docs

Mon, 01 Jan 0001 00:00:00 +0000

The definitive guide for Azure Key Vault — How to create a Key Vault and what is it

What is a Key Vault?

The definitive guide for Azure Key Vault — How to create a Key Vault and what is it

What is a Key Vault?

Azure Key Vault Overview — Azure Key Vault | Microsoft Docs

Create an Azure Key Vault by Portal

How to create an Azure Key Vault with Bicep

How to create an Azure Key Vault with Terraform

Mon, 01 Jan 0001 00:00:00 +0000

The definitive way How to consume PowerShell modules from Nuget feed on Azure DevOps

Mon, 01 Jan 0001 00:00:00 +0000

Tokenizations and Replacing tokens in Azure DevOps

In some cases, it is required that we dynamically change values in our configuration files depending on some circumstances, for instance…

Tokenizations and Replacing tokens in Azure DevOps

In some cases, it is required that we dynamically change values in our configuration files depending on some circumstances, for instance, different environments. To solve this problem, an easy solution is to leverage a Tokenization and replace the tokens process. Check out how to do this in practice.

The tokenization process consists of a configuration file with tokens defined by a pattern, that will be identified during the CD and replaced by the desired values.

Mon, 01 Jan 0001 00:00:00 +0000

Using variables files in Azure DevOps YAML Templates

Declaring variables in Azure DevOps YAML Templates

Using variables files in Azure DevOps YAML Templates

Declaring variables in Azure DevOps YAML Templates

Variables are used to inject dynamic values in your YAML Pipelines. It allows you to better organize your pipelines, keeping them more readable and organized

How to create a variable file in Azure DevOps YAML Templates

How to import a variable file in Azure DevOps YAML Templates

Mon, 01 Jan 0001 00:00:00 +0000

Variable Group in Job scope

Variable groups scoped to stage not working for task inputs — Developer Community (visualstudio.com)

Variable Group in Job scope

Variable groups scoped to stage not working for task inputs — Developer Community (visualstudio.com)

Mon, 01 Jan 0001 00:00:00 +0000

What is a Deployment Pipeline?

Deployment Pipelines Core Concepts

What is a Deployment Pipeline?

Deployment Pipelines Core Concepts

Pipeline

Build

Artifacts

Deployment

Environment

Approvals

Release

Elements of a Deployment Pipeline

Steps

Task
Script

Jobs

Stages

Triggers

Agents

Libraries

Mon, 01 Jan 0001 00:00:00 +0000

Why you should break your Azure Data Factory into small pieces

About

Mon, 01 Jan 0001 00:00:00 +0000

Welcome to my personal blog! I’m Wesley Camargo, and this site showcases my thoughts, projects, and experiences.

This blog is built with Hugo and the beautiful Stack theme, providing a clean and modern reading experience.

Contact

Feel free to reach out to me through the social links in the sidebar.

Search

Mon, 01 Jan 0001 00:00:00 +0000