DEV Community: Renicius Pagotto

Designing Effective CI/CD Pipelines: Practical Insights and Best Practices

Renicius Pagotto — Thu, 06 Feb 2025 15:10:33 +0000

In today's fast-paced development environment, modern CI/CD pipelines have become essential for delivering high-quality software efficiently. By automating key processes like testing and deployment, they enable teams to focus on innovation while minimizing risks.

Before we jump on how to design our pipelines, let's go through for some concept to make sure a comprehensive understanding.

CI/CD Pipeline

A CI/CD pipeline is an automated workflow that integrates Continuous Integration (CI) and Continuous Delivery/Deployment (CD) practices. It automates the process of building, testing, and deploying code changes, ensuring that software is delivered reliably and efficiently. The pipeline typically includes stages for code integration, automated testing, and deployment to production.

Continuous Integration

It's a practice where the code is frequently integrated in a shared branch and each integration is tested to detect early issues, ensuring that new code doesn't break existing functionality. This practice promotes early bug detection, strengthens collaboration among developers, and accelerates the development process by streamlining integration and testing.

Continuous Delivery / Deployment

There is a subtle distinction between Continuous Delivery and Continuous Deployment, but both involve automating the deployment process to eliminate manual intervention. The main difference is that Continuous Delivery includes a manual approval step before deploying code to the production environment, while Continuous Deployment automates the entire process, with or without automatic approval. Automatic approval can involve integration with tools like ServiceNow, which track changes in production and collect necessary approvals from stakeholders.

Here is a very good image demonstrating what a CI/CD pipeline looks like and how it works. It gives a clear picture of each step in the process.

Now we have a clear picture about a CI/CD pipeline, let's discuss about the step we must include in the process in order to have a reliable pipeline and guarantee a good quality for our code.

A well-designed CI/CD pipeline should include steps to ensure that the code builds successfully without any issues, incorporates thorough testing, and, most importantly, prioritizes security. Below, we will outline the process step by step.

Build and Restore

Here the download of the dependencies will happen and the code will be compiled or assembled into executable software. The build step ensures that the code is correctly structured and ready for further stages like testing and deployment. Restore is related to dependencies, in the case of .NET we have an explicit command to download only the dependencies before compilation, the same goes for Java, but not all of them are necessary, however it depends entirely on whether or not you have this specific step.

Tests

It's a pipeline step that will be to run various tests to ensure code quality. This can include unit tests, integration tests, smoke tests, and so on. It's not mandatory to have all of these types of tests, it will depend a lot on the context of the project, but at least unit tests should be present.

I would like to say that this is a mandatory step, but unfortunately not all projects have tests to run (I won't go into that discussion here), so if tests are present, this step is mandatory and the pipeline should fail if any test suite fails.

Security

This is a kind of step that it's always forgotten by teams. In general, we don't focus on security, specially when comes to docker image but is really important to have a step dedicated for it. In security step, we must cover vulnerabilities in our code, in the dependencies and specially in the image we are using as base to generate a image of our application.

This step ensures vulnerabilities are identified and addressed before deployment, reducing risks in production environments.

Vulnerabilities are classified by levels and scores (thinking specifically of the Snyk tool) and not all vulnerabilities should fail in the pipeline. We can think of it as follows.

Critical Vulnerabilities: Must fail the pipeline
High Vulnerabilities: Must fail the pipeline
Medium and Low: Do not need to fail the pipeline, but they should be addressed proactively.Teams should monitor these vulnerabilities weekly to ensure their number does not increase over time. Regular reviews and tracking help prevent the accumulation of vulnerabilities that could potentially escalate into more significant risks.

Here's a simple example of a GitHub Action where I defined 2 different steps for security.

Image security must be included in our pipeline in order to guarantee a reliable software. The vulnerability may not originate from the application or its dependencies but it can come by part of a image, that's why it's important to have a dedicated step for it.

One of the tool I like to use is Trivy, an open-source security tool that can be used to scan any kind of vulnerability in dockerfile. As Snyk, Trivy has different levels of vulnerability and can be defined a vulnerability threshold to fail the pipeline.

Here is a simple example of a security pipeline I have implemented before. It contains both Snyk and Trivy steps

Artifact

This step is responsible for generating the versioned artifact that will be deployed later, whether it’s an executable binary or a container image. The specific implementation depends on whether your application is containerized or relies on binary code.

For Containerized Applications

For containerized applications, this step involves creating a Docker image using Docker commands and pushing it to a container registry. Examples of popular registries include:

Azure Container Registry
Private Docker Hub
JFrog Artifactory

The Docker image serves as the deployable artifact, encapsulating all dependencies and configurations needed to run the application reliably across environments.

For Non-Containerized Applications

Step responsible for generating binary code (e.g., DLLs, JARs), in this case, binaries are saved to a specific versioned directory in an artifact repository like Artifactory. This ensures that each build is uniquely identifiable and traceable.

Versioning

Versioning is essential for both container images and binary artifacts. It can be implemented during this step or earlier in the pipeline by defining a version based on specific information, such as:

Labels defined in pull requests.
Commit messages or titles.

Proper versioning ensures traceability and consistency across deployments, reducing the risk of deploying incorrect artifacts.

Deployment

Deployment is the next critical step in the CI/CD pipeline, representing the Continuous Delivery or Continuous Deployment phase. This is where the binary code or container image generated during the artifact stage is used to deploy the application to environments such as Azure, AWS, GCP, or even on-premises infrastructure.

For most environments—like development, testing, and staging—this step typically runs automatically without requiring manual intervention. However, for production environments, an additional layer of control may be necessary. In such cases, an approval gateway might be implemented to ensure compliance with organizational policies before deployment proceeds.

Approval Gateway

An approval gateway is a manual step in CI/CD pipelines, primarily used in production environments to ensure compliance with organizational policies and mitigate risks. In many companies, deploying to production requires approvals from managers or stakeholders, often collected through emails or meetings. This reliance on manual intervention makes full automation impossible. However, modern tools like ServiceNow can streamline this process by integrating directly into the pipeline. For example, the pipeline can automatically create a change request in ServiceNow and pause execution until the request is approved. This integration balances automation with oversight, ensuring deployments meet compliance requirements while maintaining efficiency.

In contrast, approval gateways are unnecessary when manual approvals are not required. In such cases, pipelines can automatically deploy applications to production after passing all predefined stages, such as rigorous testing and post-deployment validations. This approach is common in Continuous Deployment scenarios, where speed and efficiency are prioritized. However, it requires well-defined pipeline steps and robust testing to minimize risks. For non-production environments like development or staging, direct deployments without manual intervention should always be encouraged to maintain agility and accelerate feedback cycles.

Post-Deployment Testing

Post-deployment testing is a crucial stage in the CI/CD pipeline, designed to validate the functionality and stability of an application after deployment. This stage can be executed after deploying to a staging environment or even after a production deployment. It involves running various test cases, such as end-to-end (E2E) tests, smoke tests, regression tests, and others, to ensure that the application operates as expected with the newly implemented features. While this stage is not mandatory, its inclusion depends on the project’s context and the agreements made within the team.

Typically, post-deployment testing is most effective when performed after deployment to a pre-production environment. This allows teams to detect and address potential issues before deploying to production. However, in Continuous Deployment scenarios, where changes are automatically pushed to production, post-deployment testing can also occur after production deployment. In such cases, having a robust validation suite is essential to catch any issues early and trigger an automated rollback process if necessary.

Rollback Mechanisms

Rollback mechanisms are an essential part of a CI/CD pipeline, designed to maintain system stability in case of deployment or post-deployment test failures. When an issue is detected—either during automated testing or through monitoring in production—the pipeline can automatically revert the application to the last known stable version. This process minimizes downtime and mitigates the impact of faulty deployments.

Automated rollback typically works by leveraging versioned artifacts or container images stored in registries or repositories. For instance, if a deployment fails, the pipeline can redeploy the previous version of the application. Rollbacks can also be triggered by monitoring tools that detect anomalies, such as increased error rates or degraded performance. Integrating rollback mechanisms ensures a safer deployment process, especially in Continuous Deployment scenarios where changes are pushed to production frequently.

Flaky Tests

Flaky tests are tests that produce inconsistent results, passing sometimes and failing others, despite no changes having been made to the underlying code. These unpredictable outcomes make it difficult to identify the root cause of the failures. Addressing flaky tests is crucial because they can erode trust in the testing pipeline, reduce productivity, obscure real issues, and delay deployments. To mitigate these problems, teams should focus on reviewing test cases, maintaining clean and well-organized test suites, and refactoring brittle or unreliable tests. These practices help ensure the reliability of automated testing, fostering a robust and efficient pipeline.

Below is an example of a common flaky test behavior

Optimization Techniques

Pipeline performance is a crucial factor in ensuring efficient and timely software delivery. A poorly optimized pipeline can lead to delays, wasted resources, and frustration for development teams. Here, we’ll explore some important optimization techniques to improve the performance and reliability of your CI/CD pipeline.

Cache Dependencies

One of the most important aspects to consider in pipeline execution is managing the dependencies required to perform its steps. Without a caching mechanism, the pipeline will repeatedly download these dependencies for every execution, significantly delaying completion and wasting resources. The same principle applies to tools like Trivy, where each execution downloads a new vulnerability database. By caching these dependencies and databases, we can reuse them in subsequent runs, reducing build times, optimizing resource usage, and improving overall efficiency. Caching not only accelerates pipelines but also ensures consistency across builds by reusing the same versions of dependencies.

Below are examples of caching dependencies in GitHub Actions to enhance pipeline efficiency. The first caches the Trivy vulnerability database to reduce scan times, and the second caches Gradle dependencies to accelerate builds. Caching improves speed and optimizes CI workflows.

Applying Parallelism: When and Why?

Parallelism is a concept that can help improve pipeline performance, but we don't always need to apply it, it depends a lot on the context.

Bringing the term parallelism to the CI/CD pipeline, we can apply this concept at various times, such as when running tests at the beginning of the execution. We don't need to run the tests sequentially, that is, first run the unit tests, then the integration tests, then the vulnerability tests. This will completely reduce the pipeline's performance and will increase the execution time for unnecessary things. We can use parallelism very well here, where everything will be executed in parallel, but the failure of one thing will not affect the execution of another thing and at the end we will have a lot of information about everything we need to fix in case of failure. The execution time in the case of parallelism is given by the process that takes the longest.

Sequential execution is applied in cases where we need to wait for the result of the previous step. A good example is the initial tests I mentioned above that can be executed in parallel where the binary generation step or the container image generation step needs to wait for the result of the previous step, in this case the unit, integration and security tests. We cannot generate artifacts that contain vulnerabilities, are of low quality and full of bugs because it is a waste of time and processing, in addition to the possibility of this code being deployed due to some human error.

Below is an example of parallelism applied to the security step, enabling multiple security checks to run simultaneously.

Conclusion

A well-designed CI/CD pipeline is not just a technical necessity but a strategic advantage in delivering reliable software quickly. By incorporating thorough testing, security measures, and optimization techniques, teams can ensure smooth deployments while maintaining high quality.

Did you enjoy this post? Interested in discussing CI/CD further? Feel free to share your questions and ideas in the comments or connect with me on LinkedIn.

The Importance of CI/CD in Modern Software Development

Renicius Pagotto — Fri, 03 Jan 2025 21:21:18 +0000

In today's software engineering process, delivering software quickly and efficiently is like a mantra. And when we think about how to deliver quickly and efficiently, the term DevOps comes to mind, more specifically the automation pillar. This is one of the most important pillars that helps to maximize the delivery process through CI/CD pipelines.

Continuous integration (CI) and continuous deployment (CD) simplify and improve the entire software development and delivery process through automation.

What is Automation?

Automation is basically the use of tools and scripts to perform tasks in an automated manner. This includes tasks like code compilation, unit and integration testing, security steps, vulnerability identification, load testing, deployment, and so on. By automating these processes, teams can streamline workflows and improve overall efficiency.

Automation is crucial for several reasons:

Efficiency and Speed: Automation reduces the time and effort required for repetitive tasks such as testing, building, and deploying code. Automated pipelines run tests and deployments much faster than manual processes, significantly reducing the time from code commit to production release. This allows developers to focus on writing code and solving complex problems.
Consistency and Reliability: Automated processes ensure tasks are performed the same way every time, reducing the risk of human error and increasing the reliability of the software. Continuous feedback from automation helps detect and address issues early in the development cycle.
Scalability: Automation enables teams to handle larger codebases and more frequent changes without a proportional increase in manual effort, making it easier to scale development processes.

What is Continuous Integration (CI)?

Continuous Integration is a development practice in which application code is integrated at least once a day (it depends a lot on the team and the context of the task). For each integration, several sets of tests, security checks, and more are automatically run to catch bugs as quickly as possible.

Note: Integration is the practice of committing changes and pushing them to the main branch or feature branch on an origin.

Key Benefits of CI:

Early Detection of Errors: Frequent code integration allows for early detection of bugs and vulnerabilities, making patching much faster, cheaper, and more efficient.
Improved Collaboration: CI promotes collaboration among team members by working on a common codebase and resolving conflicts early.
Faster Feedback: Automated tests offer immediate feedback on code quality, enabling developers to address issues promptly.

What is Continuous Delivery (CD)?

Continuous Delivery is the next step from Continuous Integration where code changes are automatically prepared for release to production. Once the code passes all automated tests and checks, the changes are manually approved and then released to the users.

What is Continuous Deployment (CD)?

Continuous deployment is an advanced practice of continuous delivery where every change that passes automated testing is automatically deployed to production without any manual intervention, ensuring that new features, bug fixes, and improvements are delivered to users as soon as they are ready, and the software is always in a deployable state.

Key Benefits of Continuous Delivery and Deployment:

Faster Time to Market: Continuous delivery and deployment enable rapid release cycles, allowing new features and updates to reach users quickly by reducing the time it takes to release new features and bug fixes.
Improved Quality and Reliability: Automated testing and deployment processes reduce the risk of human error, ensuring that only thoroughly tested code reaches production and that releases are consistent and repeatable.
Enhanced Collaboration and Productivity: By automating repetitive tasks, development teams can focus on more valuable work, fostering better collaboration and increasing overall productivity.
Reduced Manual Effort: Automation eliminates the need for manual deployment processes, further reducing the risk of human error and ensuring a more reliable software release process.

CI/CD Platforms

Here are some CI/CD platforms we can use to create pipelines

Jenkins
GitHub Actions
GitLab CI/CD
Azure DevOps
Argo CD
CircleCI

Conclusion

Continuous Integration and Continuous Deployment (CI/CD) practices are essential for modern software development, enabling teams to deliver high-quality software quickly and efficiently. By automating processes such as integration, testing, security, and deployment, CI/CD helps to detect errors early, identify code vulnerabilities, enhance collaboration, and reduce manual effort. Adopting CI/CD can significantly improve the quality and speed of software delivery, providing organizations with a competitive edge in the market.

Did you enjoy this post? Want to chat more about CI/CD? Leave a comment with your questions and ideas or connect with me on LinkedIn.

Publishing Docker images to Azure Container Registry with GitHub Actions

Renicius Pagotto — Mon, 29 Jul 2024 14:03:21 +0000

Hi everyone,

In today’s post, we will discuss how to upload Docker images to Azure Container Registry. To fully understand the step-by-step process, let’s first explore some key concepts related to the topic.

Azure Container Registry

In a nutshell, Azure Container Registry (ACR) is a service specialized in storing artifacts, including Docker images. For more information, you can access this post where I explain step by step how to create and use it.

GitHub Actions

GitHub Actions is a continuous integration (CI) and continuous delivery (CD) service provided by GitHub that lets you automate, customize, and execute software development workflows directly in your GitHub repository.

For our demonstration, we will use a .NET 8 Web API application which is essentially the default template with a Dockerfile.

GitHub Action Pipeline

This is the complete declaration of the pipeline file (.yml) where the az-registry step is the main focus. As an additional bonus of knowledge, there is a step to upload the same image to GitHub Container Registry and there is also a step to deploy the image to Azure Web Apps.

name: Build and Deploy

on:
  workflow_dispatch:
  push:
    tags:
      - '*.*.*'

env:
  IMAGE_NAME: "product-service"
  GH_REGISTRY: "ghcr.io"
  AZ_REGISTRY: "azdevdaysrpf.azurecr.io"
  AZURE_WEBAPP_NAME: az-devdays-appservice

jobs:
  gh-package:
    name: Publish | GitHub Registry
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3

      - name: Log in to the GitHub Container Registry
        uses: docker/login-action@v3
        with:
          registry: ${{ env.GH_REGISTRY }}
          username: ${{ github.actor }}
          password: ${{ secrets.GH_REGISTRY_TOKEN }}

      - name: Extract metadata (tags, labels) for Docker
        id: meta
        uses: docker/metadata-action@v5
        with:
          images: ${{ env.GH_REGISTRY }}/${{ github.actor }}/${{ env.IMAGE_NAME }}

      - name: Build and Push Image
        uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: ${{ steps.meta.outputs.tags }}

  az-registry:
    name: Publish | Azure Container Registry
    runs-on: ubuntu-latest
    outputs:
      version: ${{ steps.meta.outputs.version }}
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3

      - name: Log in to the Azure Container Registry
        uses: docker/login-action@v3
        with:
          registry: ${{ env.AZ_REGISTRY }}
          username: ${{ secrets.AZ_SP_CLIENT_ID }}
          password: ${{ secrets.AZ_SP_CLIENT_SECRET }}

      - name: Extract metadata (tags, labels) for Docker
        id: meta
        uses: docker/metadata-action@v5
        with:
          images: ${{ env.AZ_REGISTRY }}/${{ env.IMAGE_NAME }}

      - name: Build and Push Image
        uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: ${{ steps.meta.outputs.tags }}

  deploy:
    name: Azure Web App Deployment
    runs-on: ubuntu-latest
    needs: [ gh-package, az-registry ]
    steps:
      - name: Login Azure
        env:
          AAD_SERVICE_PRINCIPAL_CLIENT_ID: ${{ secrets.AZ_SP_CLIENT_ID }}
          AAD_SERVICE_PRINCIPAL_CLIENT_SECRET: ${{ secrets.AZ_SP_CLIENT_SECRET }}
        run: |
          az login --service-principal -u ${{ secrets.AZ_SP_CLIENT_ID }} -p ${{ secrets.AZ_SP_CLIENT_SECRET }} --tenant ${{ secrets.AZ_TENANT_ID }}
          az account set -s ${{ secrets.AZ_SUBSCRIPTION_ID }}
          az account show

      - name: Azure Web Apps Deployment
        uses: azure/webapps-deploy@v3
        with:
          app-name: ${{ env.AZURE_WEBAPP_NAME }}
          images: ${{ env.AZ_REGISTRY }}/${{ env.IMAGE_NAME }}:${{ needs.az-registry.outputs.version }}

Let's start with the first part of the pipeline where below we have an image and also the explanation.

name: The name of the pipeline.

on: Specifies the trigger for the pipeline. In this case, the pipeline is triggered every time a new tag (git tag) is pushed. We also define the format of the git tag required to execute the pipeline, typically following the standard versions like 0.0.1 or 1.0.0.

env: Represents the global environment variables for the pipeline context.

IMAGE_NAME: The name assigned to the Docker image.

AZ_REGISTRY: The URL of the Azure Container Registry.

Let's dive into the az-registry stage now and explain the steps in detail, as this is where all the crucial actions take place.

In this stage, we are using a Linux runner called ubuntu-latest.

Checkout Repository: This step downloads the repository to the GitHub runner.

Docker Buildx: This installs Docker along with the extended plugin called Buildx.

Login to Azure: We log in to Azure to enable image uploads using a Service Principal with contributor access to the Azure Container Registry.

Extract Metadata: Retrieve metadata (such as tags and labels) and define the full name of the image.

Build and Publish: In this final step, we run the Dockerfile, tag the image named in the previous step, and upload it to Azure Container Registry.

Finally, to execute the pipeline, define a tag using the git tag command and push the tag to the origin. Here are examples of the commands.

git tag 1.0.0
git origin push 1.0.0

Did you enjoy this post? Want to chat more about it? Leave a comment with your questions and ideas, or connect with me on LinkedIn.

GitHub Repository: https://github.com/reniciuspagotto/az-devdays-dotnet-container?wt.mc_id=studentamb_72239

Azure Container Registry — Storing images and artifacts

Renicius Pagotto — Sat, 27 Jul 2024 19:56:34 +0000

Hi everyone, in today’s post we’re going to talk about Azure Container Registry, a great alternative to Docker Hub for storing both public and private images and artifacts.

We’ll also learn how to use Azure CLI and Docker CLI for creating and uploading Docker images.

What is Azure Container Registry?

It's a service for storing and managing images and artifacts, based on Docker Registry technology.

Azure Container Registry supports OCI distribution, which is a vendor-agnostic specification responsible for enabling the storage, sharing, and protection of artifacts and images.

What are Artifacts?

Artifacts are objects used by a process, such as Dockerfile, appconfig, appsettings, Helm charts, and others.

Basic Concepts of Azure Container Registry

Azure Container Registry has some basic concepts like namespaces, repositories and tags that are essential for proper usage of the resource.

Repository

A repository is a collection of images or artifacts with the same name but different tags. A repository may include a namespace to help identify related repositories. Namespaces are used by separating names with a slash.

Here we have some examples of repositories

productapi:v1
productapi:v2
productapi:latest

Here are some examples of repositories with namespace as prefix

product/productapi:v1
product/catalogapi:v1
notification/emailapi:v1
notification/pushapi:v1

Demonstration

In today’s demonstration, we will explain the step-by-step process of provisioning an Azure Container Registry account through the Azure Portal and also via Azure CLI. Additionally, we will demonstrate how to create and upload an image to the registry.

Prerequisites

Azure account
Visual Studio Community
Azure CLI
Docker Desktop

Provisioning Azure Container Registry via the Azure Portal

Open the Azure Portal and in the search bar, type the name of the resource, in this case, Azure Container Registry, and then select it.

On the next screen showing the resource list, click on + Create.

On this screen, we need to provide some information that will be used to create the resource.

For better understanding, here is a detailed explanation of each piece of information:

Subscription: The name of the subscription that will be used for provisioning the new service.

Resource Group: The name of the resource group to be used, which is associated with the subscription. If you don't have one, select the option Create new below the dropdown to create a new one.

Registry name: The name to be given to the service.

Location: The region where the service will be provisioned.

Availability Zones: When selected, this offers high availability and resilience for all registries.

SKU: The tier of service desired. Available tiers are Basic, Standard, and Premium, each with its own features.

Next, click on Review + Create. After the resource manager validates the information, click on Create.

Once the provisioning of the new Azure Container Registry account is complete, access it and select Repositories from the sidebar menu.

Within the Repositories option is where images are stored. However, since we just created the resource, the repository is empty.

Provisioning Azure Container Registry via Azure CLI

Another way to provision Azure Container Registry is through Azure CLI, the command line interface. To do this, we will use a series of commands detailed below.

With Azure CLI installed on your machine, the first step is to authenticate to your Azure account using the following command:

az login

Once authenticated, you need to set the subscription that will be used for provisioning resources. Use the following command:

az account set -s name-of-subscription

The az account command sets which resource we want to access in Azure, in this case, our subscription. The set command specifies that we want to define a specific subscription, and the -s argument is where we pass the name of the desired subscription.

After authentication and setting the subscription, we will provision a new Azure Container Registry resource using the following command:

az acr create -g "resource-group-name" -n "resource-name" --sku sku-name

The az acr create command specifies the desired resource and the action to be taken. The acronym acr stands for Azure Container Registry, and the action create is used to create the resource. Other available actions include delete, update, list, and more.

The -g or --resource-group argument is where you define the resource group to be used, which must be associated with a subscription. The -n or --name argument is used to name the resource, and finally, the --sku argument specifies the desired service tier. If no information is provided, the resource will be created with the Standard tier by default.

After executing this command, a new Azure Container Registry resource will be provisioned, and you can view it through the Azure Portal.

An important point to note is that each Azure Container Registry resource has a URL for managing artifacts. This information can be found on the resource’s page and is labeled as the Login server.

Creating the Project and Dockerfile

For today’s demonstrations, we need a simple API project that includes a Dockerfile for creating a Docker image.

To do this, we will create a new project in Visual Studio with the Docker option enabled.

With the creation of the new project completed, note that the solution includes a Dockerfile with all the necessary configurations, ready to use. Keep in mind that this Dockerfile is provided with the project template.

We have now completed the creation of a basic project, using the default template provided by .NET. However, the most important part is the Dockerfile, which we will use to build our image.

Creating and Uploading the Image with Docker CLI

With Docker CLI properly installed on your machine, the first step is to create an image of our application using the Dockerfile.

Open your command line terminal, navigate to the root folder of the application we just created, and execute the following command to build the image:

docker build -t image-name -f AzureApiContainer/Dockerfile .

The docker build command specifies the desired action. The -t argument is where we pass the desired name for our image, the -f argument specifies the location of the application’s Dockerfile, and the final dot represents the context for executing the Dockerfile.

Once the image is built, run the docker images command to verify the image. In my case, I named the image azureapicontainer.

Now it’s time to rename the image to include the URL of our registry server (Login server), which is the Azure Container Registry.

docker tag azureapicontainer:latest pagottoacr.azurecr.io/azureapicontainer:v1

A new image will be created using the name and tag we just specified.

The command for adding a new tag along with the service URL works as follows:

docker tag image-name:tag login-server/destination-image-name:tag

The docker tag command creates a new version of the same image with a different tag and name. We need to specify both the source image and the destination image. For the destination image, we must prefix the name with the registry server URL, which is the Login Server URL from the Azure Container Registry page mentioned earlier.

With the image ready for upload, we first need to authenticate with the Azure Container Registry. Use the following command for authentication:

az acr login -n azure-container-registry-name

The az acr login command performs the authentication (login) to the Azure Container Registry (acr). The -n argument should be followed by the name of the Azure Container Registry account/service used to store the image.

After authentication, we are ready to upload the image using the following command:

docker push server-image-name:tag

The docker push command uploads the image, and you need to specify the image to be used. In this case, we use the image with the registry server name. Docker will use the specified server name to connect and perform the upload.

In my case, I used the following command to upload the image:

docker push pagottoacr.azurecr.io/azureapicontainer:v1

Creating and Uploading the Image with Azure CLI

To create an image using Azure CLI, we will use Azure Container Registry Tasks (ACR Tasks), which are commands for creating, sending (uploading), and executing a container image natively in Azure, without the need to have Docker installed locally.

To create an image via Azure CLI, open your command line terminal, navigate to the root folder of the application, and execute the following command:

az acr build -t "image-name" -r registry-name -f dockerfile-directory .

The az acr build command specifies the desired action, in this case, creating a new image. The -t argument is where you define the name of your image. The -r argument specifies the name of the Azure Container Registry you will use. The -f argument is the location of the Dockerfile for your application, and the final dot represents the context in which the Dockerfile will be executed.

When you run the command, the creation and upload of the image will be handled automatically by Azure Container Registry.

Viewing the Image in Azure Container Registry

After creating and uploading an image via Docker CLI or Azure CLI, open the Azure Portal again and select the Azure Container Registry resource that you provisioned.

In the sidebar menu, select Repositories.

With that, you can finally see our image stored in the service.

By accessing the repository, we can view the different available versions.

With this, our image is stored in Azure Container Registry and available for use in any process.

Did you enjoy this post? Want to chat more about Azure Container Registry? Leave a comment with your questions and ideas or connect with me on LinkedIn.

Referências
Azure Container Registry Documentation

Publishing image to GitHub Container Registry using GitHub Actions

Renicius Pagotto — Wed, 31 Jan 2024 11:50:04 +0000

Hi everyone, in today's post we are going to talk about how to create images and publish to GitHub Container Registry using GitHub Actions.

Base Knowledge

For a deeper understanding of the subject, it's advisable to understand the concepts of Docker and GitHub Container Registry and to help you with this, I have left two useful links below.

What is Container Registry?

Docker Overview

Application Implementation (.NET)

The first step is basically to create a new project in .NET, feel free to use your favorite IDE to do this. We'll use a .NET API project, so we can containerize the application and publish it as an image on GitHub Container Registry.

When creating the project, remember to include support for docker on Linux if your IDE offers this option

Note: I'm using JetBrains Rider

In the project we will not implement anything new, we will only use what is already in the standard template, as the main objective is just to generate an image of the application. For more information about the project I created, you can see it here .NET Core API

If you forgot to enable docker support through the IDE or if the IDE does not have this type of support, let's manually add the dockerfile to the root of the project. Remember to review and make the necessary changes to the dockerfile, especially the application name if it's different.

FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS base
USER $APP_UID
WORKDIR /app
EXPOSE 8080
EXPOSE 8081

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
ARG BUILD_CONFIGURATION=Release
WORKDIR /src
COPY ["
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/83cihjqtpx8722tm137p.png)

.Api/ImageApplication.Api.csproj", "ImageApplication.Api/"]
RUN dotnet restore "ImageApplication.Api/ImageApplication.Api.csproj"
COPY . .
WORKDIR "/src/ImageApplication.Api"
RUN dotnet build "ImageApplication.Api.csproj" -c $BUILD_CONFIGURATION -o /app/build

FROM build AS publish
ARG BUILD_CONFIGURATION=Release
RUN dotnet publish "ImageApplication.Api.csproj" -c $BUILD_CONFIGURATION -o /app/publish /p:UseAppHost=false

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "ImageApplication.Api.dll"]

After creating the application and configuring the dockerfile, ensure that it works as expected. You can download Docker Desktop or Rancher Desktop and run it locally to ensure the image will build correctly.

Now, push the code to a new GitHub repository as for the next steps it's essential to have the repository created.

Generating GitHub Token

The next step is to generate the token that will represent the secret to authenticate to GitHub Container Registry and allow publication. In the right menu, go to Settings

In the left menu, go to Developer settings

Let's use a classic token

Click the Generate new token dropdown and select Generate new token (classic)

Set a name for your token, the expiration date and select the write:packages scope

At the bottom, click on the green Generate Token button to actually create the token and obtain the secret.

Go back to the repository you created for the .NET application. Now let's use the GitHub Secret to store the token to be used by the pipeline. To do this, in the repository. select Settings

In the left menu, select Secret and variables and click Actions.

Select New repository secret, define a name for the secret and in values paste the token we generated earlier. Finally, click Add secret.

Now we have the token that will be used for authentication and publication authorization as a GitHub Secret where it will be used by the pipeline.

Pipeline / Workflow

After creating our project, configuring the dockerfile and authentication token, it's time to prepare our CI/CD pipeline to generate the image and publish it to the Container Registry.

The pipeline itself is simple and easy to understand, as you can see below

Let's understand part by part

Name: Represents the name of the workflow

on: It's the trigger of workflows

push: It's the type of trigger, for example, the pipeline will be executed on every push

tags: As we defined the trigger of our pipeline as a push event, we also need to inform the push type, in our example it will be a tag push with a pre-defined format.

The pipeline/workflow will always be triggered every time a tag push occurs that follows the pattern

In the next part, we define the pipeline environment variable.

The registry variable represents the Container Registry URL, provided by GitHub.

The image name variable represents the name of my repository, which will also be used to name the image.

Next part, we have the definition of jobs where we need to define at least one job, the OS to be used by the Runner and the necessary steps.

Checkout Repository -> It's basically a git clone of the repository inside the VM (Runner) that will execute the steps.

Set up Docker Buildx -> Command for installing Docker Buildx that will be responsible for executing docker commands.

Log in to the GitHub Container Registry -> It's the authentication step in the Container Registry. Note that we pass 3 variables for step, registry, username and password. Registry is the URL defined in the environment variable at the beginning of the pipeline, username is your username on GitHub and is accessible by the standard variable github.actor provided by GitHub itself and the last is the password which is our token that we created previously and which is stored as secret where we reference it using the name REGISTRY_TOKEN.

In the last part we have...

Extract metadata... -> It's the command to make the git tag be used as the image version.

Build and Push Image -> Finally, this is the step that runs the dockerfile, creates the image, and pushes it to the Container Registry.

Executing the pipeline

To run the pipeline, you need to create a git tag and submit it, the commands are shown below.

git tag 1.3.0
git push origin 1.3.0

I've set a version of 1.3.0, but feel free to use whatever version you like. After push, the pipeline will run automatically.

To view packages, you can go to your profile again and select Packages

You can now download and run the image from any location. Remembering that the image is published as private, to make it public just click on the image and make it visible to everyone.

That's all folks, stay tuned for the next posts.

Publishing Nuget in GitHub Packages

Renicius Pagotto — Tue, 30 Jan 2024 12:52:38 +0000

Hi everyone, in today's post we will talk about how to create Nuget packages (C#) and publish to GitHub packages using GitHub Actions.

Base Knowledge

For a complete understanding of the subject, it's advisable to understand the concepts of Nuget and GitHub Packages and to help you with this, I have left two useful links below.

What is Nuget?

Introduction to GitHub Packages

Implementing .NET / Nuget Package

The first step is to create a new project in .NET, you can use your favorite IDE to do this. This project should be a simple class library as it is just a package that contains reusable implementations.

Note: I'm using JetBrains Rider

In my project I implemented some basic methods just for example, you can see the implementation details here Common Packages

After implementing what you need in your .NET project, create a new repository on GitHub and push your code. The next steps will be necessary to already have the repository created.

Generating GitHub Token

The next step is to generate the token that will represent the secret to authenticate to GitHub Packages and allow publication. In the right menu, go to Settings

In the left menu, go to Developer settings

Let's use a classic token

Click the Generate new token dropdown and select Generate new token (classic)

Set a name for your token, the expiration date and select the write:packages scope

At the bottom, click on the green Generate Token button to actually create the token and obtain the secret.

Go back to the repository you created for the .NET application (Nuget Package). Now let's use the GitHub Secret to store the token to be used by the pipeline. To do this, in the repository. select Settings

In the left menu, select Secret and variables and click Actions.

Select New repository secret, define a name for the secret and in values paste the token we generated earlier. Finally, click Add secret.

Now we have the token that will be used for authentication and publication authorization as a GitHub Secret where it will be used by the pipeline.

Pipeline / Workflow

Once we have our application implemented and the publishing token configured, it's time to prepare our CI/CD pipeline to generate the package and publish it to GitHub packages.

The pipeline itself is simple and easy to understand, as you can see below

Let's understand part by part

Name: Represents the name of the workflow

on: It's the trigger of workflows

push: It's the type of trigger, for example, the pipeline will be executed on every push

tags: As we defined the trigger of our pipeline as a push event, we also need to inform the push type, in our example it will be a tag push with a pre-defined format.

Basically, the pipeline / workflow will be triggered with each push of tags that follow the pattern (..*)

In the second part, we have the definition of jobs where we need to define at least one job, the OS to be used by the Runner and the necessary steps.

Checkout Repository -> It's basically a git clone of the repository inside the VM (Runner) that will execute the steps.

Set up .NET Core -> Step to download and install dependencies to run .NET commands

Build -> It's a build of the application to ensure everything is working

In the last part we have

Package -> It's the command to create a nuget package in .NET where the package name will be the same as the project name and the version will be the git tag.

Publish -> Finally, this is the step that takes the nuget package generated in the previous step and publishes it to GitHub Packages

To publish to your GitHub package, simply point to your GitHub Packages, that is, just replace the username in the url as shown below.

nuget.pkg.github.com/your-username/index.json

Note that I'm using a secret in the publish command, called "NUGET_AUTH_TOKEN" which is basically the secret we created previously with the token that allows publishing.

Executing the pipeline

To run the pipeline, you need to create a git tag and submit it, the commands are shown below.

git tag 1.5.0
git push origin 1.5.0

I've set a version of 1.5.0, but feel free to use whatever version you like. After push, the pipeline will run automatically

To view packages, you can go to your profile again and select Packages

Now, you can import the package into your .NET project by pointing to the GitHub package URL. Remembering that the package is published as private, to make it public just click on the package and make it visible to everyone.

That's all folks, stay tuned for the next posts.

Azure App Spaces (preview) Overview

Renicius Pagotto — Tue, 30 Jan 2024 12:52:07 +0000

Hi everyone, in today's post we're going to talk about Azure App Spaces, a new service from Azure (Microsoft) that promises to facilitate the creation and deployment of applications.

This new service has two main functions, one of them helps to define the best service(s) to be used by the application through an analysis that Azure itself carries out in the repository.

The other feature is to select an out-of-the-box template that you may to use and Azure will take care of deploying the entire application and necessary infrastructure. There are currently 4 main templates you can choose from, as seen below.

React Container App with C# API and PostgreSQL
React Web App with Python API and MongoDB
Static React Web App with Node.js API and MongoDB
React Web App with C#/.NET and SQL Database

Note: All information has been extracted from the Azure Portal, so it can be changed at any time as the service is still in preview.

You can see the default page of Azure App Spaces bellow

Microsoft Definition

To better understand what this new service is all about, here is an official explanation from Microsoft's documentation.

Azure App Spaces is an intelligent service for developers that reduces the complexity of creating and managing web apps. It helps you identify the correct services for your applications on Azure and provides a user-friendly management experience that's streamlined for the development process.

App Spaces offers all the benefits of deploying an app via existing Azure services, like Container Apps, Static Web Apps, and App Service, with an experience that's focused on making you develop and deploy faster.

Azure App Spaces is still in preview, so be aware that potential bugs may be encountered.

Note: The only supported service is GitHub for now, but as the service is in preview, new ways of integrations may be added in the future.

Using an existing repository – How does it work?

I have prepared two different scenarios to better explain how the service works.

Scenario 1

In the first scenario, we're going to use a simple HTML page. Basically I just created a simple HTML file on GitHub and pushed the code in the main branch, you can do the same thing.

On the Azure App Spaces default page, select the Start deploying option as shown below.

Select the Organization, Repository and Branch you'd like to deploy.

After that, the service will analyze the entire repository and advice you about the best service. In my case, Azure suggested using Azure Static Web App demonstrating good accuracy, as it was in fact the most suitable service.

Scrolling down, we need to define some information about the application and also the details of creating the Azure Static Web App.

Once deployment begins, magic happens. On deployment, Azure creates and adds a CI/CD (GitHub Actions) pipeline to the repository you selected to use. Although the pipeline is very simple, it's enough to deploy the application.

The resources were automatically created in Azure, so you don't have to worry about that either.

Scenario 2

In the second example, we will use a .NET project that I implemented. Again, go to the App Spaces home page, select the Start deploying option and select the new repository with the .NET project. The suggestion was to use Azure App Service and again the choice was very assertive.

Once the deploy button is clicked again, a new CI/CD pipeline will be added to the repository and the required resources will be created automatically.

Using Templates - How does it work?

Now, let's demonstrate how to use templates. Basically if you want to start a new app, you can use a out-of-the-box template and just adapt according to your needs.

As I said, we currently have 4 templates available to be used and for this scenario, we'll select the React Web App template with C#/.NET and SQL Database.

Select the template, define some information and click the deploy button.

Azure will start creating your application and the resources run it. The entire process take a while to be completed.

In summary, once the process is completed, we have a new GitHub repository with the application (front-end and back-end) and a CI/CD pipeline to deploy the code.

Also in the repository we have a directory called infra, inside we find a bicep file (IaC) which is basically the application infrastructure at code level where all the configuration necessary to run the application is ready, without the need for any adjustments.

The CI/CD pipeline is responsible for deploying the infrastructure by executing the biceps file and also the application itself.

You will have an entire application up and running without the need to set a connection between back-end and database or between front-end and back-end.

Powerful, isn't it?

Brief Summary

Let's highlight the main points:

The resource only supports GitHub
There are same templates with out-of-the-box application.
A CI/CD pipeline is used to deploy the infrastructure together bicep file when using a template.
CI/CD pipeline is also used to deploy the application
All application settings and keys (secrets) are included in the pipeline or in bicep, you don't need to adjust anything.

Note: I haven't tested other scenarios but the process is basically the same as we demonstrated above. I also don't know if the accuracy of the analysis will be good in complex scenarios, but I'll bring new tests in the future.

Highlighting an important point, when using templates, a new repository is created containing all the files needed to deploy both the application and the infrastructure, it's possible to redeploy if necessary, while using an existing repository, Azure will just create the pipeline of CI/CD to deploy the application, you don't have the biceps file to create the infrastructure.

Conclusion

Although the feature is in preview, it's an excellent option to help and improve software delivery in companies. With its analysis capacity, it will certainly be a very useful tool to help you decide which is the best resource to use in a given scenario.

The templates will speed up the creation and delivery of the software to customers, since all aspects have already been adjusted, so the focus will be entirely on the functionalities that will need to be developed.

One more thing to mention, when using templates, in addition to just creating the application and infrastructure, Azure provides good security practices, such as creating an instance of the Azure Key Vault already set with the application, the connection between the back-end and the database is done via managed identity, among many other things that I could see by analyzing the repository. It's really not just the experience of creating a solution and executing it, it's the experience of having a ready-to-use solution, with a good level of security associated, with the best possible practices.

Reference
https://learn.microsoft.com/en-us/azure/app-spaces/overview

Azure Static Web Apps with Vue.js and Visual Studio Code

Renicius Pagotto — Sat, 11 Feb 2023 18:24:14 +0000

Hey everyone, in today's post we are talking about how deploy an Vue.js Application to Azure Static Web App using Visual Studio Code.

To understand what is Azure Static Web App, visit Azure Static Web Apps - The Big Picture

Prerequisites

NPM
Vue CLI
Visual Studio Code
Azure Static Web App extension for Visual Studio Code
Git

Implementation

Once you have all the prerequisites installed, let's create the project itself. For that, let's use the command line and run the command below to create a Vue.js project.

vue create <vue-project-name>

After creating the project, let's open it in Visual Studio Code. You can open the project using the interface or by typing the command below in your command line tool.

code .

Important: Always access the project root before opening in Visual Studio Code or you can open VS Code first and then open the project root. Always avoid opening in the folder before the project as this can lead to errors in the build and consequently in the pipeline.

The next step is the deployment, so Press F1 and search for Azure Static Web App: Create Static Web Apps and select.

In the next step, we need to select the Azure Subscription, but if you are not logged into your Azure account with Visual Studio Code, an option to make the connection will be displayed.

In the next option, we need to define the name to be given to the service in Azure.

Now, we need to define a name for the GitHub Repository

The next step is to define the region where the resource will be created.

Now it's time to define the project type. Note that Azure Static Web Apps supports multiple frameworks and since our project is a Vue.js project, we should select the Vue option.

Here we need to set the path to the root of the Vue project. By doing this, the executor responsible for deploying the code will be able to run the npm run build command to generate the outputs in the dist directory. Let's set / to this option.

In the last step, we need to define the application build output path and for Vue.js projects we need to inform the dist folder.

Finally, press enter to start creating the resource on Azure and creating the repository on GitHub.

Once the run is complete, we have an instance of Azure Static Web Apps provisioned in Azure and ready to use, and the repository on GitHub with our code. At the end, the code deployment pipeline will be executed automatically by GitHub Actions.

Now, let's open the Azure Portal to get the link of our the Web Site in Azure Static Web App resource.

With the link copied, paste it into your browser to see the result or you can simply click on the link to be redirected automatically.

Conclusion

Azure Static Web Apps is a powerful feature that makes it easy and fast to build and deliver a modern front-end project.

Did you like this post? Want to talk a little more about it? Leave a comment with your questions and ideas or get in touch through LinkedIn.

Azure Static Web Apps with Angular and Visual Studio Code

Renicius Pagotto — Sat, 11 Feb 2023 18:24:01 +0000

Hey everyone, in today's post we are going to talk about how to deploy an Angular app to Azure Static Web App using Visual Studio Code.

To better understand what is Azure Static Web App, visit Azure Static Web Apps - The Big Picture

Prerequisites

NPM
Angular CLI
Visual Studio Code
Azure Static Web App extension for Visual Studio Code
Git

Once you have all prerequisites installed, let's create an Angular project and for that, create a new folder in any directory you want on your machine. You can create it using the operating system's interface, or if you prefer, run the command below in your command line tool to create a new folder.

mkdir <folder-name>

Now, using the command line, go to the folder you just created and run the command below to create an Angular project.

ng new <angular-project-name>

After creating the project, let's open it in Visual Studio Code. You can open the project using the interface or by typing the command below in your command line tool.

code .

Important: Always access the project root before opening in Visual Studio Code or you can open VS Code first and then open the project root. Always avoid opening the folder of the project you created in the previous folder, as this can lead to errors in the build and consequently in the pipeline

The next step is the deployment, so Press F1 and search for Azure Static Web App: Create Static Web Apps and select.

In the next step, we need to select the Azure Subscription, but if you are not logged into your Azure account with Visual Studio Code, an option to make the connection will be displayed.

In the next option, we need to define the name to be given to the service in Azure.

In the next step, it is time to define a name for the GitHub repository

The next step is to define the region where the resource will be created.

Now it's time to define the project type. Note that Azure Static Web Apps supports multiple frameworks and since our project is a Angular project, we should select the Angular option.

Here we need to set the path to the root of the Angular project which is /. By doing so, the runner responsible for processing the code deployment pipeline will be able to run the ng build command to generate the outputs in the dist directory.

In the last step, we need to define the application build output path and for Angular projects we need to inform the dist folder and the project name.

Finally, press enter to start creating the resource on Azure and creating the repository on GitHub.

If you are getting this type of error as shown below

Just remove the following line, in the browserslistrc file in the root of the project

And try to deploy the app or run the app again.

Now, let's open the Azure Portal to get the link of our the Web Site in Azure Static Web App resource.

With the link copied, paste it into your browser to see the result or you can simply click on the link to be redirected automatically.

Conclusion

Azure Static Web Apps is a powerful feature that makes it easy and fast to build and deliver a modern front-end project.

Did you like this post? Want to talk a little more about it? Leave a comment with your questions and ideas or get in touch through LinkedIn.

Azure Static Web Apps - The Big Picture

Renicius Pagotto — Sat, 11 Feb 2023 18:23:45 +0000

Hey everyone, today we're going to talk about Azure Static Web App and how this feature can help you improve and speed up the deployment of static web apps.

Introduction

Azure Static Web Apps is a new cloud-based service that automatically builds and deploys your web app to Azure directly from your repository. It's is fully integrated with popular source code managers like GitHub, GitLab, BitBucket and Azure DevOps.

Key Features

Azure Static Web Apps is a global service, so your app's static resources are distributed globally and cached.
Once your project is created, the CI/CD pipeline is also created with the project and runs automatically, making your project available in minutes.
Built-in API support provided by Azure Functions
Free SSL certificates, which are automatically renewed
Unique preview URLs to preview Pull Request changes

Architectural Considerations

Static web apps can be created using popular frameworks like React, Angular, Vue, Svelt or even Blazor, as they consist of a collection of static content like HTML, CSS and Javascript, which usually depend on an API to provide data.

Azure Static Web Apps supports Azure Functions, so it is possible to create an API together in the project, that is, in addition to creating a static project that will be in an app/ directory in the project, it is also possible to develop an endpoint using the Azure Functions that will be in an api/ folder within the same project, with this we can have a separation of static content and API, allowing each to be scaled using the most appropriate and cost-effective technology.

This architecture with static content servers, serverless backends (Azure Functions) and automated CI/CD workflows simplifies your development workflow, allowing you to focus your attention on application logic and user experience components of your modern web application.

When to use it?

In creating modern web applications with front-end structures such as Angular, React, Vue, Next and other frameworks.
In creating landing pages and personal websites using only HTML, Javascript and CSS.

Show me the code

For this demo, let's create a project that contains just one HTML file that will represent a very simple landing page.

Prerequisites

GitHub account
Azure account
Visual Studio Code
Azure Static Web App extension for Visual Studio Code
Git

Once all prerequisites are installed, open Visual Studio and create a directory with the name of your choice. In this directory, we will create an HTML file and define an HTML tag with a text as shown in the image below.

With that, we basically have a code ready to carry out the deployment and the next step is exactly that.

Press F1 and search for Azure Static Web App: Create Static Web Apps and select.

In the next step, we need to select the Azure subscription, if you are not logged into your Azure account with Visual Studio Code, an option to connect will appear.

Once we select the signature, a pop-up appears on the screen informing that it is necessary to create a repository to store the code, so click on the Create button.

In the next step, we need to create a message to confirm before pushing our code to the repository. Type the message you want and press Enter.

Now the Azure Static Web Apps extension needs access to your GitHub account to store the code. Click the Allow button to be redirected to authenticate your account.

The popup below will not appear if you are already logged into your account.

In the next step, we return to the Azure Static Web Apps settings and now we need to define the name to be given to the service.

In the next option we need to define a name for the GitHub Repository.

The next step is to define the region where the resource will be created.

Now it's time to define the project type. Note that Azure Static Web Apps supports multiple frameworks and since our project is a simple index.html file, we should select the Custom option.

Here we need to define the path to reach the index.html file, but as the index is at the root of the directory, just define / for this option.

In the last step, we need to define the application build output path, however as our application is a simple HTML file, we don't need to define anything, however if the project was from some other framework, we would need to define the path to the dist folder or whatever another pattern.

Press enter to start creating the resource.

Now let's go to the Azure portal to check the resource that was created.

Selecting the resource, let's copy the url and paste it in our browser.

Github Actions

After completing all the steps, a directory called github is created in your project and inside it we can see that a yml has been created. This yml file represents the project's deployment pipeline.

Note that this pipeline was triggered automatically on GitHub.

Temporary URL

There is an amazing feature which is the possibility of having a temporary URL to analyze the changes made to the code in the Pull Request. Once the pull request is finished, the url will no longer be available for use.

To start the demo, create a new branch based on the main branch, feel free to name it whatever you like. Now, being in this new branch, let's add some new text in the code.

Now, let's commit and push the new code

In the next step, we'll open a Pull Request and wait for the pipeline to finish executing.

To get the temporary URL, click the Actions tab and select the run based on your new branch.

Click Build and Deploy Job in the left menu and then select Build and Deploy.

Scroll down to the bottom to see the URL.

Now, copy and paste into your browser to see the change.

Conclusion

Azure Static Web Apps is a powerful feature that makes it easy and fast to build and deliver a modern front-end project.

Did you like this post? Want to talk a little more about it? Leave a comment with your questions and ideas or get in touch through LinkedIn.

Azure Static Web Apps with React and Visual Studio Code

Renicius Pagotto — Sat, 11 Feb 2023 17:23:05 +0000

Hey everyone, in today's post we are talking about how deploy an React Application to Azure Static Web App using Visual Studio Code.

To understand what is Azure Static Web App, visit Azure Static Web Apps - The Big Picture

Prerequisites

NPM
Visual Studio Code
Azure Static Web App extension for Visual Studio Code
Git

Installing React Framework

Once all the prerequisites are installed on your machine, the next step is to install React, for that run the command below.

npm install -g create-react-app

Creating a ReactJS project

Now that you have React installed, you can create a new react project directory by running the command below

npx create-react-app <project-name>

After creating the project, let's open it in Visual Studio Code. You can open the project using the interface or by typing the command below in your command line tool.

code .

The next step is the deployment, so Press F1 and search for Azure Static Web App: Create Static Web Apps and select.

In the next step, we need to select the Azure Subscription, but if you are not logged into your Azure account with Visual Studio Code, an option to make the connection will be displayed.

In the next option, we need to define the name to be given to the service in Azure.

In the next step, it's time to define a name for the GitHub repository

The next step is to define the region where the resource will be created.

Now it's time to define the project type. Note that Azure Static Web Apps supports multiple frameworks and since our project is a React project, we should select the React option.

Here we need to set the path to the root of the React project. By doing this, the executor responsible for deploying the code will be able to run the npm run build command to generate the outputs in the build directory. Let's set / to this option.

In the last step, we need to define the application build output path and for React projects we need to inform the build folder that it's generate by build command.

Finally, press enter to start creating the resource on Azure and creating the repository on GitHub.

Now, let's open the Azure Portal to get the link of our the Web Site in Azure Static Web App resource.

With the link copied, paste it into your browser to see the result or you can simply click on the link to be redirected automatically.

Conclusion

Azure Static Web Apps is a powerful feature that makes it easy and fast to build and deliver a modern front-end project.

Did you like this post? Want to talk a little more about it? Leave a comment with your questions and ideas or get in touch through LinkedIn.

Understanding Azure Event Hubs Capture

Renicius Pagotto — Thu, 22 Dec 2022 12:38:45 +0000

Hello everyone, today we are going to talk about data capture in Azure Event Hubs and understand how this feature can empower data processing and storage.

What is Event Hubs Capture?

It's a feature of Azure Event Hub that allows Azure Blob Storage or Azure Data Lake Storage Gen 1 and Gen 2 to automatically receive all events sent to the hub with the flexibility to specify a time interval or size.

According to Microsoft, setting up Capture is fast, there are no administrative costs to run it, and it scales automatically with Event Hubs throughput units in the standard tier or processing units in the premium tier.

For more information, please visit Azure Event Hubs Capture.

Important

The destination storage (Azure Storage or Azure Data Lake Storage) account must be in the same subscription as the Azure Event Hubs.
Azure Event Hubs does not support capturing events in an Azure Premium Storage account.

When to use?

A good scenario to use Azure Event Hubs Capture is for event retention where, once captured, we can replay those events.

Another use case would be Event Sourcing, where you can store all the events that happened in your application.

Another scenario that Azure Event Hubs Capture allows you to focus on data processing instead of data capture.

How to create a Azure Event Hubs resource?

Open the Azure Portal and in the search engine type Azure Event Hubs and select the resource.

Select +Create option

Now, we need to provide some information that will be used to create the resource, feel free to provide the names you want. Once completed, at the bottom of the page select Review + create to validate the information and select Create when validation is complete to create the resource.

This operation may take a few minutes and after that your resource will be available to be used in the application.

Now, we need to create a Hub that will receive the application's events. From the left menu, select Event Hubs and then select + Event Hub

We need to provide some information for creating the Hub, again feel free to name it as you wish. Once completed, at the bottom of the page, select Review + create to validate the information and select Create when validation is complete to create the resource.

After that, the hub will be available for use.

How to enable Event Hub Capture?

Now, it's time to enable the Capture feature, but before that, you need to create an Azure Blob Storage and a container or an Azure Data Lake to use to receive the events. In my demo scenario I will use Azure Blob Storage.

After creating the resource that will receive the events, open the Event Hub we created above and select the Capture option, select Avro as serialization format and enable capture.

Apache Avro is a data serialization system, for more information visit Apache Avro

Now we need to define some information that Azure Event Hubs Capture will use to capture the events and send it to the target resource.

Below we have the explanation of the information:

Time window - The time interval in which the data will be collected, in this case every 5 minutes the data will be captured and sent to the target resource.
Size window - The amount in MB of events that the process will capture. The default value is 300 MB.
Do not emit empty files when no events occur during the Capture time window - Once the checkbox is checked, the capture will only capture events that have information, if no events are found, then nothing will be sent to the target destination.
Capture Provider - Here we define the destination of events which can be Azure Blob Storage or Azure Data Lake.
Azure Storage Container or Data Lake Store - This information is based on the previous one, if you set the Capture Provider as Azure Blob Storage then you need to select the container to receive the events, if you set it as Azure Data Lake then you need to inform the Data Lake name and Data Lake Path.
Sample Capture file name formats - Here we define the path format for storing the event.
Capture file name format - This format will follow the format of the Sample Capture File Name Formats field.

Below is a simple example of the way to find the event in Azure Blob Storage.

e.g. customer-event/customer-created/0/2022/12/20/13/06/53

In my case, I chose Azure Blob Storage as the Capture Provider and defined the container that will receive the events.

After filling, select Save changes to definitely enable the feature.

Once capture is enabled, all events are automatically captured every 2 minutes in 300MB batches and sent to Azure Blob storage.

Show me how it works

To demonstrate how it works, I created an event producer to publish them in the event hub.

Basically, this producer is an API project that contains an HTTP POST endpoint that, once the request is made, will publish an event in the hub of a created user.

        [HttpPost]
        public async Task<IActionResult> SendEvent()
        {
            var eventHubConnectionString = _configuration.GetValue<string>("EventHub:Connection");
            var eventHubName = _configuration.GetValue<string>("EventHub:ProductHubName");

            var producerClient = new EventHubProducerClient(eventHubConnectionString, eventHubName, new EventHubProducerClientOptions
            {
                RetryOptions = new EventHubsRetryOptions
                {
                    MaximumRetries = 5,
                    Delay = TimeSpan.FromSeconds(2)
                }
            });

            var eventBatch = await producerClient.CreateBatchAsync();

            var obj = new
            {
                Name = "Renicius Pagotto",
                Email = "test@test.com",
                Age = 30
            };

            eventBatch.TryAdd(new EventData(Encoding.UTF8.GetBytes(JsonSerializer.Serialize(obj))));
            await producerClient.SendAsync(eventBatch);

            return Ok($"The event has been published on {DateTime.Now}");
        }

Below is the postman request

Now is the time to view the event in Azure Blob Storage and for that, we must use the format that was defined in the capture resource, which basically represents the file path.

In my scenario, my time zone is GMT-3 which means I need to add 3 hours from the time the message was posted so I can get the correct time as Azure works with UTC.

So to find the event in Azure Blob Storage the path is 2022 - 12 - 20 - 13 - 18 - 27

And opening the file, we can see the information we posted.

Project: https://github.com/reniciuspagotto/eventhub-producer-consumer

Did you like this post? Want to talk a little more about? Leave a comment with your questions and ideas or get in touch through LinkedIn.

DEV Community: Renicius Pagotto

Designing Effective CI/CD Pipelines: Practical Insights and Best Practices

CI/CD Pipeline

Continuous Integration

Continuous Delivery / Deployment

Build and Restore

Tests

Security

Artifact

For Containerized Applications

For Non-Containerized Applications

Versioning

Deployment

Approval Gateway

Post-Deployment Testing

Rollback Mechanisms

Flaky Tests

Optimization Techniques

Cache Dependencies

Applying Parallelism: When and Why?

Conclusion

The Importance of CI/CD in Modern Software Development

What is Automation?

What is Continuous Integration (CI)?

Key Benefits of CI:

What is Continuous Delivery (CD)?

What is Continuous Deployment (CD)?

Key Benefits of Continuous Delivery and Deployment:

CI/CD Platforms

Conclusion

Publishing Docker images to Azure Container Registry with GitHub Actions

Azure Container Registry

GitHub Actions

GitHub Action Pipeline

Azure Container Registry — Storing images and artifacts

What is Azure Container Registry?

What are Artifacts?

Basic Concepts of Azure Container Registry

Repository

Tag

Demonstration

Prerequisites

Provisioning Azure Container Registry via the Azure Portal

Provisioning Azure Container Registry via Azure CLI

Creating the Project and Dockerfile

Creating and Uploading the Image with Docker CLI

Creating and Uploading the Image with Azure CLI

Viewing the Image in Azure Container Registry

Publishing image to GitHub Container Registry using GitHub Actions

Base Knowledge

Application Implementation (.NET)

Generating GitHub Token

Pipeline / Workflow

Executing the pipeline

Publishing Nuget in GitHub Packages

Base Knowledge

Implementing .NET / Nuget Package

Generating GitHub Token

Pipeline / Workflow

Executing the pipeline

Azure App Spaces (preview) Overview

Microsoft Definition

Using an existing repository – How does it work?

Scenario 1

Scenario 2

Using Templates - How does it work?

Brief Summary

Conclusion

Azure Static Web Apps with Vue.js and Visual Studio Code

Prerequisites

Implementation

Conclusion

Azure Static Web Apps with Angular and Visual Studio Code

Prerequisites

Conclusion

Azure Static Web Apps - The Big Picture

Introduction

Key Features

Architectural Considerations

When to use it?