
Managing a monorepo with multiple Python packages presents unique challenges, particularly in ensuring efficient CI/CD. In this article, I will share how I created CI/CD workflows for our monorepo of Python packages using GitHub Actions.

We will delve into the workflows, including matrix complexity, and scripts for checking changed paths, alongside other custom scripts and composite actions that facilitate this process.

Our primary CI workflow (`on-pr-build-push.yaml`) triggers on pull requests, ensuring that all changes are validated before merging. This workflow comprises several jobs: `ChangedPaths`, `Lint`, `Typecheck`, `Test`, and `Build-Push`.

__Job: ChangedPaths__

This job determines which packages have been modified and outputs a matrix that drives the subsequent jobs. So for example, if a PR modifies `package1` and `package2`, the matrix will contain two rows: `package1` and `package2`.

```yaml
name: Build & Push Python Package

on:
  pull_request:

jobs:
  ChangedPaths:
    runs-on: ubuntu-latest
    outputs:
      matrix: ${{ steps.get_changed_paths.outputs.matrix }}
    timeout-minutes: 10
    permissions:
      id-token: write
      contents: read
    
    steps:
      - name: Checkout
        uses: actions/checkout@v3
        with:
          token: ${{ secrets.GLOBAL_GITHUB_TOKEN }}
          fetch-depth: 0

      - name: Run init
        uses: ./.github/actions/init # Custom composite action for initializing the environment
      
      - name: Get Changed Paths
        id: get_changed_paths
        shell: bash
        run: |
          python $GITHUB_WORKSPACE/.github/scripts/internal/get_changed_paths.py
```

The `get_changed_paths.py` python script identifies the changed paths and filters them to include only those within the packages directory.
This script is quite straightforward and uses the `git diff` command by using the built-in `subprocess` module in order to identify the changed paths.

```python
import subprocess
import os

output_file = os.getenv('GITHUB_OUTPUT')


def get_changed_paths():
    cmd = 'git diff --name-only $(git rev-parse HEAD) HEAD~1'
    result = subprocess.run(cmd, shell=True, capture_output=True)
    if result.returncode != 0:
        raise Exception("Error getting changed paths")

    changed_paths = result.stdout.decode("utf-8").strip().split("\n")
    print(f"Changed paths: {changed_paths}")
    return changed_paths


def get_filtered_paths(changed_paths):
    filtered_paths = set()
    for path in changed_paths:
        if path.startswith("packages/"):
            filtered_paths.add(path.split("/")[1])
    print(f"Filtered paths: {filtered_paths}")
    return list(filtered_paths)


if __name__ == "__main__":
    changed_paths = get_changed_paths()
    filtered_paths = get_filtered_paths(changed_paths)
    print(filtered_paths)
    with open(output_file, "a") as file:
        file.write(f"matrix={filtered_paths}")
```

Note the `capture_output=True` argument allows us to capture the command's output. We then decode and split the output to get a list of changed paths. The `get_filtered_paths` function filters these paths to include only those that start with `packages/` which is my path in my repos case.

Also note that GitHub Actions uses environment files to pass data between steps and jobs. By writing the output matrix to a file (GITHUB_OUTPUT), we can ensure that the list of changed paths is available as an output in the ChangedPaths job. This allows subsequent jobs to access and iterate over the paths efficiently.

__Job: Lint, Typecheck, and Test__

These jobs runs composite actions for linting (flake8), type checking (mypy), and tests (pytest) on the changed packages using a matrix strategy. They depend on the ChangedPaths job.

```yaml
  Lint:
    needs: ChangedPaths
    if: ${{ needs.ChangedPaths.outputs.matrix != '[]' }}
    strategy:
      matrix: 
        path: ${{ fromJson(needs.ChangedPaths.outputs.matrix) }}
    runs-on: ubuntu-latest
    timeout-minutes: 10
    permissions:
      id-token: write
      contents: read

    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Get path
        run: echo ${{ matrix.path }}
      
      - name: Run init
        uses: ./.github/actions/init
        with: 
          change_path: ${{ matrix.path }}

      - name: Run Lint action
        uses: ./.github/actions/lint
        env: 
          paths: ${{ matrix.path }}
```

__Job: Build-Push__

The final job in the CI pipeline builds and pushes the packages if all previous jobs succeed.

```yaml
  Build-Push:
    needs: [ChangedPaths, Lint, Typecheck, Test]
    if: ${{ needs.ChangedPaths.outputs.matrix != '[]' }}
    strategy:
      matrix:
        path: ${{ fromJson(needs.ChangedPaths.outputs.matrix) }}
    runs-on: ubuntu-latest
    timeout-minutes: 15
    permissions:
      id-token: write
      contents: read

    steps:
      - name: Checkout
        uses: actions/checkout@v3
        id: checkout

      - name: Run init
        id: run-init
        uses: ./.github/actions/init
        with: 
          change_path: ${{ matrix.path }}

      - name: Build & Publish Python Packages
        uses: ./.github/actions/build-push-package
        env: 
          paths: ${{ matrix.path }}
```

This job calls a custom composite action (`build-push-package`) that builds and upload the package to GitHub cache, so the user can install it from there.

```yaml
name: Build & Release Package
description: "Build & Push Python Package"
author: "Or Kazaz"

runs:
  using: composite

  steps:
    - name: Checkout
      uses: actions/checkout@v3
      with:
        fetch-depth: 0

    - name: Setup Python
      uses: actions/setup-python@v4
      with:
        python-version: '3.11'

    - name: Install Python Dependencies
      shell: bash
      run: |
        pip install --upgrade pip
        pip install poetry twine check-wheel-contents

    - name: Run Poetry Check for pyproject.toml
      working-directory: ./packages/${{ env.paths }}
      shell: bash
      run: poetry check

    - name: Build Package Distribution
      working-directory: ./packages/${{ env.paths }}
      shell: bash
      run: poetry build

    - name: Check Distribution Descriptions
      working-directory: ./packages/${{ env.paths }}
      shell: bash
      run: |
        twine check dist/*

    - name: Check Wheel Contents
      working-directory: ./packages/${{ env.paths }}
      shell: bash
      run: |
        check-wheel-contents dist/*.whl

    - name: Cache Package Distribution
      uses: actions/upload-artifact@v3
      with:
        name: ${{ env.paths }}
        path: ./packages/${{ env.paths }}/dist/
```

The secondary workflow (`tag-and-release.yaml`) is triggered on a manually on demand by using `workflow_dispatch`. It tags the package, updates its version is pyproject.toml.toml, and publish the packages into our internal PyPI repository (on Jfrog Artifactory). It consists of multiple jobs to ensure a smooth release process.

__Job: Tag and Release__

This job tags the repository and creates a release on GitHub by zipping it and using an action to create a release to be available for download.

```yaml
jobs:
  tag-and-release:
    runs-on: ubuntu-latest
    timeout-minutes: 15

    outputs:
      package_version: ${{ steps.dynamic_version.outputs.package_version }}

    steps:
      - name: Checkout
        uses: actions/checkout@v3
        with:
          ref: ${{ github.event.inputs.commit_hash }}

      - name: Run Dynamic-Versioning
        id: dynamic_version
        uses: ./.github/actions/dynamic-versioning
        with:
          package_name: ${{ github.event.inputs.package_name }}

      - name: Archive package directory
        working-directory: ./packages
        run: |
          zip -r ${{ github.event.inputs.package_name }}.zip ./${{ github.event.inputs.package_name }}
          echo "ARTIFACT_FILE_PATH=./packages/${{ github.event.inputs.package_name }}.zip" >> $GITHUB_ENV
        env:
          ARTIFACT_FILE_PATH: ${{ env.ARTIFACT_FILE_PATH }}

      - name: Create Release
        uses: ncipollo/release-action@v1
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          artifacts: "${{ env.ARTIFACT_FILE_PATH }}"
          commit: ${{ github.event.inputs.commit_hash }}
          tag: ${{ github.event.inputs.package_name }}-v${{ steps.dynamic_version.outputs.package_version }}
          name: ${{ github.event.inputs.package_name }}-v${{ steps.dynamic_version.outputs.package_version }}
          token: ${{ secrets.GLOBAL_GITHUB_TOKEN }}
          skipIfReleaseExists: true
```

Note that the `dynamic-versioning` action is a custom action that updates the version in the `pyproject.toml` file.

```yaml
name: "Dynamic Versioning"
description: "Bump version in python package"
author: "Or Kazaz"

inputs:
  package_name:
    description: "Package name"
    required: true

outputs:
  package_version:
    description: 'bumped package version'
    value: ${{ steps.bump_version.outputs.package_version }}

runs:
  using: composite

  steps:
    - name: Checkout
      uses: actions/checkout@v3
      with:
        fetch-depth: 0

    - name: Bump version
      id: bump_version
      shell: bash
      run: |
          PACKAGE_VERSION=$($GITHUB_WORKSPACE/.github/scripts/internal/bump_version.sh ${{ inputs.package_name }})
          echo "${{ inputs.package_name }} package will be bumped to version: ${PACKAGE_VERSION}"
          echo "package_version=$PACKAGE_VERSION" >> $GITHUB_OUTPUT
```

Bump version is a very simple bash script the increments the package version in the `pyproject.toml` file.

```bash
#!/bin/bash

PACKAGE_NAME=$1

VERSION_LINE=$(grep version ./packages/$PACKAGE_NAME/pyproject.toml)
OLD_VERSION=$(echo "$VERSION_LINE" | awk -F'"' '{print $2}')
NEW_VERSION=$(echo "$OLD_VERSION" | awk -F. -v OFS=. '{$3=$3+1}1')

sed -i "s/$VERSION_LINE/version = \"$NEW_VERSION\"/g" ./packages/$PACKAGE_NAME/pyproject.toml

VERSION=$(grep version ./packages/$PACKAGE_NAME/pyproject.toml | awk -F'\"' '{print $2}')
echo $VERSION
```

__Job: Build__

This job builds the package distribution using Poetry.

```yaml
  build:
    needs: tag-and-release
    name: Build Python Package
    runs-on: ubuntu-latest
    timeout-minutes: 30

    steps:

      - name: Checkout
        uses: actions/checkout@v3
        with:
          ref: ${{ github.event.inputs.commit_hash }}

      - name: Setup Python
        uses: actions/setup-python@v4
        with:
          python-version: '3.11'

      - name: Install Python Dependencies
        working-directory: ./packages/${{ github.event.inputs.package_name }}
        run: |
          pip install --upgrade pip
          pip install --upgrade poetry twine check-wheel-contents

      - name: Run Dynamic-Versioning
        id: dynamic_version
        uses: ./.github/actions/dynamic-versioning
        with:
          package_name: ${{ github.event.inputs.package_name }}

      - name: Build Package Distribution
        working-directory: ./packages/${{ github.event.inputs.package_name }}
        run: |
          poetry build
```

__Job: Publish to JFrog__

This job publishes the built package to JFrog by retrieving the cached package distribution and using the official `gh-action-pypi-publish` action.

```yaml
  publish-jfrog:
    needs: build
    name: Publish Package to JFrog
    runs-on: ubuntu-latest
    timeout-minutes: 15

    steps:
      - name: Retrieve Cached Package Distribution
        uses: actions/download-artifact@v3
        with:
          name: ${{ github.event.inputs.package_name }}
          path: ./packages/${{ github.event.inputs.package_name }}/dist

      - name: Publish to JFrog
        uses: pypa/gh-action-pypi-publish@release/v1
        with:
          packages-dir: ./packages/${{ github.event.inputs.package_name }}/dist
          user: ${{ secret.secret_user }}
          password: ${{ secret.secret_password }}
          repository-url: https://the.internal.repo.url/artifactory/api/pypi/pypi

```

__Job: Commit Updated Version__

Finally, this job commits the updated version to the repository while skipping CI.


```yaml
  commit-version:
    needs: [tag-and-release, build, publish-jfrog]
    name: Commit updated version
    runs-on: ubuntu-latest
    timeout-minutes: 15

    steps:
    - name: Checkout
      uses: actions/checkout@v3

    - name: Commit updated version
      shell: bash
      run: |
          git config --global user.name $GITHUB_USER
          git config --global user.email $GITHUB_EMAIL
          git pull
          bash $GITHUB_WORKSPACE/.github/scripts/internal/bump_version.sh ${{ github.event.inputs.package_name }}
          git add ./packages/${{ github.event.inputs.package_name }}/pyproject.toml
          git commit -m "Bump ${{ github.event.inputs.package_name }} to version ${{ needs.tag-and-release.outputs.package_version }} [skip ci]"
          git push origin ${GITHUB_REF#refs/heads/}
```

![CI-ON-PR](https://res.cloudinary.com/dtt2usukl/image/upload/v1718703406/Image_18-06-2024_at_12.36_ge6oku.jpg)*On Pull request CI of 3 packages modified*

This setup ensures that only the affected packages are processed, reducing build times and resource usage. The use of matrix strategies, custom scripts, and composite actions provides a flexible, generic and scalable approach to managing CI/CD workflows of such use case.


In this article i'll share how I handheld the CI/CD in a mono repo with multiple python packages using GitHub Actions.

Handling CI/CD in a Mono Repo With Multiple Python Packages


We've implemented extensive improvements, including expanding device capacity, enhancing monitoring systems, introducing features like automated recovery mechanisms, chaging regions using internal network VPN and more.
These advancements will streamline testing processes, optimize resource utilization, and provide a seamless experience for developers and testers across global locations.
With ~250 users, supporting 25 different platforms and 150 testing devices, we are well-positioned for continued success.

For those of you who are not familiar with DAZN, here's a brief overview:

> *DAZN is the world’s leading live sports BTC streaming service. With DAZN, fans in any country can watch sport in any language, on any device, live and on-demand. Purpose built to stream live sports globally, DAZN is the market leader in Italy, Spain, Germany, and Japan, where it holds the top-tier domestic football rights — Serie A, La Liga, Bundesliga and J League, respectively — as well as the richest catalogue of live and on-demand content. DAZN is also available in over 200 other territories, where it boasts the most extensive library of elite and emerging sports content.*

DAZN develops both HTML-based and native applications designed to run on a variety of platforms, including TVs, set-top boxes, gaming consoles, and native devices. Ensuring high quality across these diverse platforms necessitates thorough testing at every stage of development, ranging from unit tests and component tests to emulator tests and real-device testing.

The global pandemic in 2020 prompted a paradigm shift in work practices, underscoring the importance of enabling engineers to access diverse resources and conduct testing remotely. Quality remains paramount, necessitating comprehensive testing methodologies despite remote work environments.

To address these challenges, we adopted a proactive “Lab as a Service” approach, culminating in the establishment of an in-house lab facility in Katowice, Poland. This strategic decision aimed to centralize resources and provide engineers with the necessary tools and infrastructure to conduct testing efficiently.

However, establishing and operating an in-house lab posed unique challenges that required careful consideration and resolution. These challenges encompassed logistical, technical, and organizational aspects, underscoring the need for adaptive solutions and collaborative efforts.

In response to these challenges, ongoing initiatives are focused on optimizing the efficiency and effectiveness of the in-house lab, streamlining workflows, enhancing collaboration among teams, and leveraging technology to overcome geographical barriers. By embracing innovation and agility, DAZN aims to continuously improve its testing capabilities and deliver exceptional quality across its diverse range of applications and platforms.

## Challenges

DAZN employs a diverse team of developers and test engineers spread across different global locations such as Poland, India, Israel, and the UK. Each team comes with its unique set of needs and requirements, necessitating a robust, highly available, and cost-effective platform to accommodate them effectively.

Key points include:

- Diverse Platform Support:
The platform must ensure comprehensive testing across all platforms supported by DAZN, emphasizing thoroughness and quality assurance in our testing procedures.
    
- Tailored Solutions:
Teams may require different tools and resources for their testing processes; for instance, some teams may rely on manual UI/UX testing devices, while others prioritize automation solutions.
    
- Integration Challenges:
Incorporating in-house tools and services into our platform is essential to ensure seamless continuity for engineers, requiring careful integration efforts.
    
- Scalability and Maintenance:
The platform needs to support a large number of engineers on a daily basis across multiple global sites, balancing scalability with efficient maintenance to avoid operational bottlenecks.

- Cost Considerations:
Maintaining devices, infrastructure, and manpower across various locations can incur significant expenses, necessitating a cost-effective approach to resource allocation and management.

- Ownership and Accountability:
Clear ownership and accountability structures are crucial to prevent issues such as maintenance gaps or device mismanagement.

To address these challenges, ongoing efforts are focused on streamlining processes, enhancing collaboration between teams, and leveraging automation wherever possible to optimize resource utilization and improve efficiency in our testing and development workflows.


## Solution — Lab as a Service

Our team, composed of seasoned experts in DevOps, Automation Infrastructure, and IT, recognized the need for a novel solution to address the challenges faced in managing Device Under Test (DUT) usage at DAZN. In the first quarter of 2023, we conducted a comprehensive assessment to identify and map out the major pain points associated with DUT utilization within the organization. This assessment culminated in the development of a pioneering approach coined “Lab as a Service,” aimed at alleviating the burden on developers and testers by handling all DUT-related tasks and physical infrastructure management.

During the second quarter of 2023, we introduced the Minimum Viable Product (MVP) setup, leveraging the Suitest framework — a vendor offering remote control and automation capabilities tailored for both HTML-based and native platforms. Our team meticulously orchestrated the deployment of all requisite physical infrastructure, assembling a dedicated lab housing 50 test devices within a spacious room at the DAZN Katowice office.

![DUT lab v1.0 (QA room — May 2023)](https://miro.medium.com/v2/resize:fit:640/format:webp/1*MDbJo7nq77qwWrRCpNvsrA.jpeg)*DUT lab v1.0 (QA room — May 2023)*

To bolster reliability and resilience, we implemented a comprehensive monitoring and alerting system, with Grafana serving as the frontend interface. Additionally, we integrated DUT recovery mechanisms to enhance the robustness of our testing environment.

![Grafana monitoring dashboard](https://miro.medium.com/v2/resize:fit:640/format:webp/1*8a9dpHjMLH1FZCQptCNplw.png)*Grafana monitoring dashboard*

The efficacy of these enhancements became apparent swiftly, as an increasing number of engineers gravitated towards utilizing the centralized lab infrastructure instead of configuring local devices. Leveraging the valuable feedback provided by users, we iteratively refined and enhanced the lab environment, ensuring that it continues to meet the evolving needs of our development and testing teams.

## Lab as a service 2.0

As the user base and the number of devices in the DAZN lab continued to surge, spurred by the establishment of a new DAZN site in India and the expansion of supported platforms throughout the latter half of 2023, we undertook further enhancements to the Katowice lab. These adjustments were aimed at accommodating the organization’s growth and fortifying its capacity to scale even further. Throughout the first quarter, we initiated a series of improvements targeting both the physical infrastructure and supporting features:

### Infrastructure enhancements

- __Relocation and Expansion:__

The DUT lab underwent relocation to a larger space, facilitating increased scalability and the seamless onboarding of additional platforms and devices. Leveraging existing racks more efficiently, we enabled the mounting of devices on both sides of each rack, resulting in a 50% boost in the number of TVs and a 40% increase in the number of set-top boxes (STBs), totaling 120 DUTs overall, with ample room for further expansion.

![DUT lab v2.0 (open space — January 2024)](https://miro.medium.com/v2/resize:fit:640/format:webp/1*IKUuw6aU2wQMzTBKCKS_bA.jpeg)*DUT lab v2.0 (open space — January 2024)*

- __Streaming Solutions:__

Collaborating with Suitest, we identified a cost-effective solution enabling the streaming of device HDMI output for STBs and gaming consoles. Additionally, we enhanced the TV streaming setup by refining the phone streaming app.

![Live DUT Streaming Phone camera setup](https://miro.medium.com/v2/resize:fit:720/format:webp/1*K460jjXRPqXUVQf8PVg0ng.jpeg)*Live DUT streaming mobile phone camera setup*

![HDMI grabber/splitter combo](https://miro.medium.com/v2/resize:fit:640/format:webp/1*s-cKLE8Oh1h5mliovKc91Q.jpeg)*HDMI grabber/splitter combo*

### Features enhancements

- __Collaboration with Suitest:__

Over the course of the year, we actively collaborated with Suitest to influence their roadmap, contributing to improvements in user experience and interface. A significant milestone was the introduction of a Unified UI integrating video streaming, remote control, and logs within the same browser window, enhancing productivity for lab users.

![Suitest Unified UI](https://miro.medium.com/v2/resize:fit:640/format:webp/1*Wg96k859tBYZwz13vVXG3Q.png)*Suitest Unified UI*

- __LR (Living Room) Launcher__:

In collaboration with the DAZN LivingRoom development team, we introduced LR Launcher, simplifying the workflow for manual testers and streamlining the onboarding process for partner platforms such as Sky and Movistar for the sake of ease of use when testing different development environments.


![LR Launcher](https://miro.medium.com/v2/resize:fit:640/format:webp/1*5AObQs1_Vdyd9cXhf5qF3w.png)*LR Launcher*

- __Enhanced Monitoring__:

With the growing user base and device count, robust monitoring became paramount. We revamped our monitoring service, streamlining processes and transitioning from an API-based solution to WSS notifications. Furthermore, we expanded monitoring coverage and implemented alerting for control units and streaming devices.

- __Automated Recovery__:

Leveraging smart plugs across all TV platforms, we implemented remote manual and automated recovery mechanisms for malfunctioning DUTs. Efforts are underway to develop similar mechanisms for cameras and control units, bolstering the resilience and efficiency of our lab environment.

- __Local Tunnel__:

A local tunnel solution providing exposure of a local development server allows developers and testers to seamlessly execute their code on a real physical lab device. This capability not only streamlines the testing process but also provides a practical and authentic environment for validating local code during development.

- __Lab Insights Report (BI)__:

An automated report detailing lab usage and testing trends. This report will provide valuable insights into usage patterns, enabling us to further optimize our services based on real data.

![BI Report](https://res.cloudinary.com/dtt2usukl/image/upload/v1716458627/Image_27-08-2023_at_11.58_sas9dh.jpg)*BI Report*

__VPN Change Region & VPN Console__:

A VPN solution that will empower lab users to seamlessly transfer DUTs between regions remotely. Using firewalls controlled by OPNSense, a lambda backend and a UI portal written in React (NextJS) users are able to testing of region-dependent content across all lab devices by switching regions as needed.

![VPN Console](https://res.cloudinary.com/dtt2usukl/image/upload/v1716458833/Image_23-05-2024_at_13.06_oxbech.jpg)*VPN Console*

## Service & Support

- __Continuous Improvement:__

Since the launch of the DUT lab in May 2023, we have continually bolstered our service and support infrastructure. This includes expanding our support engineering team, enhancing documentation and guides, and maintaining accessible support channels during working hours. Our commitment to swift issue resolution is underscored by our expanded remote resolution capabilities, facilitated by proactive monitoring and device error-based recovery processes.

- __Onboarding Optimization:__

Through the introduction of “Lab as a Service 2.0” and tailored training sessions, we have streamlined the onboarding process for new users, ensuring a seamless transition and maximizing productivity from the outset using official docs portal (using github pages and backstage).

These enhancements collectively represent our ongoing commitment to optimizing the DAZN lab environment, fostering innovation, and empowering our engineering teams to deliver exceptional quality across all platforms and devices.


## Acknowledgements

Special thanks to the amazing AP Nexus team for their dedication and hard work, it was a pleasure working with each one of you!

[Dennis Groisman](https://www.linkedin.com/in/dennis-groisman-9811b335/), [Daniel-Shahar Cohen](https://www.linkedin.com/in/danielshaharcohen/), [Rafal Muszalik](https://www.linkedin.com/in/rafa%C5%82muszalik/), [Blazej Milewski](https://www.linkedin.com/in/blazej-milewski/), [Alex Rivkin](https://www.linkedin.com/in/alex-rivkin-b037a6a1/), [Yoav Brown](https://www.linkedin.com/in/yoav-brown-970b55265/) and the one and only [Gal Moran](https://www.linkedin.com/in/gal-moran-a3454095/).


[![DAZN Lab as a Service](https://res.cloudinary.com/dtt2usukl/image/upload/v1716460903/play_video_lab_fnkajn.jpg)](https://res.cloudinary.com/dtt2usukl/video/upload/v1716460249/tvlab_v2_withmusic_twifar.mp4 "DAZN Lab as a Service - Nexus Team")*My team - Lab as a Service 2.0*


Article on [Medium (DAZN Engineering Blog)](https://medium.com/dazn-tech/lab-as-a-service-in-dazn-9bcc9d549970)


I'm incredibly proud to share the outstanding work our team has accomplished recently in upgrading our testing lab infrastructure.

Lab as a Service in DAZN


In this blog post i'll share a real world example of how to create an S3 bucket with a redirect URL using Cloudfront with Terraform.

This started at my work when we needed to create a simple redirect URL for a specific domain referring to the company's official documentation portal. Our goal was to create a simple URL that would redirect to the documentation portal for our specific team for our internal customers in the company, which would make it easier for them to access.

Our solution involves creating an S3 bucket configured to redirect requests, setting up a CloudFront distribution for global reach, responses, etc, and configuring a Route 53 DNS record to point to our CloudFront distribution.

Here's how these AWS services work together in our setup:

* AWS S3 Bucket: Hosts a redirect rule to our desired URL.

* AWS CloudFront: Distributes our content globally.

* AWS Route 53: Manages DNS to make our short URL accessible.

Let's start with our example:

__Setting Up the S3 Bucket for Redirection__

Our first step is to create an S3 bucket that will handle the URL redirection using Terraform:

```hcl
resource "aws_s3_bucket" "redirect_bucket" {
  bucket = "your-bucket-name"

  website {
    redirect_all_requests_to = "https://the-url-you-want-to-redirect-to.com"
  }
}
```

This snippet creates an S3 bucket and sets it up to redirect all incoming requests to our specified URL. The website block is used to configure the bucket as a static website, and the redirect_all_requests_to attribute specifies the URL to redirect to.


__Configuring the CloudFront Distribution__

Next, we set up a CloudFront distribution to serve our content globally. Here's the example configuration:

```hcl
resource "aws_cloudfront_distribution" "s3_distribution" {
  origin {
    domain_name = "${aws_s3_bucket.redirect_bucket.bucket}.s3-website.${var.region}.amazonaws.com"
    origin_id   = "S3-${aws_s3_bucket.redirect_bucket.id}"

    custom_origin_config {
      http_port              = 80
      https_port             = 443
      origin_protocol_policy = "http-only"
      origin_ssl_protocols   = ["TLSv1.2"]
    }
  }

  # ... Additional configuration ...
}
```

This sets up a CloudFront distribution that points to our S3 bucket. Note how we configure the custom_origin_config to ensure secure content delivery.
Also, make sure that in the origin block, you specify the correct resource name for the S3 bucket (domain_name).

__Setting Up Route 53 for DNS Configuration__

For our short URL to be accessible, we need to configure a DNS record in Route 53:

```hcl
resource "aws_route53_record" "www" {
  zone_id = data.aws_route53_zone.selected.zone_id
  name    = "your-name"
  type    = "A"

  alias {
    name                   = aws_cloudfront_distribution.s3_distribution.domain_name
    zone_id                = aws_cloudfront_distribution.s3_distribution.hosted_zone_id
    evaluate_target_health = false
  }
}
```
This Terraform code creates an A record that points to our CloudFront distribution. Make sure to replace your-name with the desired domain name and to understand what's needed in terms or DNS record type.

Keep in mind, this is a simplified example of how to set up an S3 bucket with a redirect URL using CloudFront with Terraform. You may need to adjust/add configurations based on your specific requirements and use case.


Real world example of how to create an S3 bucket with a redirect URL using Cloudfront with Terraform.

S3 Bucket Redirect URL With Terraform


Microsoft Authentication Library or MSAL is a library that enables web applications to authenticate users against Azure Active Directory (AAD). This setup can be crucial for applications requiring secure identity management and access control, especially within organizations using Microsoft services.

MSAL JS library supports protocols such as OAuth2 and OpenID Connect, making it easier to implement for web applications.

So let's begin.

### Registering Your Application with Azure AD

First, you need to register your application with Azure AD to obtain valid credentials for authentication.

1. Sign into the Azure Portal: Navigate to Azure Portal.
2. Create a New App Registration: Go to Azure Active Directory > App registrations > New registration. Make sure you select SPA applications.
3. Configure Redirect URIs: For development, and in my case, I used `http://localhost:3000/`. Ensure not to enable Implicit Grant or Hybrid Flows.

![Azure-SPA-Registered](/images/azure-spa-register.jpeg)

### Setting Up Your Next.js Project

Initialize a new Next.js project if you haven't already:

```bash
npx create-next-app msal-next-auth --use-npm
cd msal-next-auth
npm install @azure/msal-react @azure/msal-browser
```

### Configuring MSAL in Your Next.js App

Create a configuration file for MSAL and initialize the MSAL instance.

In my case I created a file named `msal.js` in `services/` directory:

```javascript
import { PublicClientApplication } from "@azure/msal-browser";

const msalConfig = {
    auth: {
        clientId: process.env.NEXT_PUBLIC_AZURE_AD_CLIENT_ID,
        authority: `https://login.microsoftonline.com/${process.env.NEXT_PUBLIC_AZURE_AD_TENANT_ID}`,
        redirectUri: process.env.NEXT_PUBLIC_REDIRECT_URI
    }
};

const msalInstance = new msal.PublicClientApplication(msalConfig);
export { msalInstance };
```

Ensure you have set the environment variables in `.env.local`:

```bash
NEXT_PUBLIC_AZURE_AD_CLIENT_ID=your-client-id
NEXT_PUBLIC_AZURE_AD_TENANT_ID=your-tenant-id
NEXT_PUBLIC_REDIRECT_URI=/
```

Note that the `redirectUri` should match the one you configured in Azure AD.
Also, note that NEXT_PUBLIC env vars (browser env vars) are being applied only in during build time and not in runtime. Which means if these env vars are environment dependent, you should take it into account in your CI that handles the application build and deployment.

Next, Modify `_app.js` to Use MSAL Provider:

```javascript
import { MsalProvider } from '@azure/msal-react';
import { msalInstance } from '@/services/msal';
import '.@/styles/globals.css';

function MyApp({ Component, pageProps }) {
  return (
    <MsalProvider instance={msalInstance}>
      <Component {...pageProps} />
    </MsalProvider>
  );
}

export default MyApp;
```

### Adding Authentication to Your Pages

Here you can use MSAL React hooks which makes your life easier and add authentication functionality.

For example, in `pages/index.js`:

```javascript
import { AuthenticatedTemplate, UnauthenticatedTemplate, useMsal } from '@azure/msal-react';
import React from 'react';

function SignInButton() {
    const { instance } = useMsal();
    return <button onClick={() => instance.loginRedirect()}>Sign In</button>;
}

function WelcomeUser() {
    const { accounts } = useMsal();
    const username = accounts[0]?.name || 'Guest';
    return <p>Welcome, {username}</p>;
}

export default function Home() {
    return (
        <div>
            <AuthenticatedTemplate>
                <WelcomeUser />
            </AuthenticatedTemplate>
            <UnauthenticatedTemplate>
                <SignInButton />
            </UnauthenticatedTemplate>
        </div>
    );
}
```
Note that you can use the token acquired from MSAL to call your API with authentication header (if required) or use any other attribute from the token object such as name from the example.

You can also use the `useIsAuthenticated` hook to check if the user is authenticated and show different content accordingly. 

```javascript
import { useIsAuthenticated } from '@azure/msal-react';

export default function Home() {
    const isAuthenticated = useIsAuthenticated();
    return (
        <div>
            {isAuthenticated ? <WelcomeUser /> : <SignInButton />}
        </div>
    );
}
```

In one of my projects at work I created a custom hook to use the token in the API calls:

```javascript
import { useMsal } from '@azure/msal-react';

export const useAccessToken = () => {
  const { instance, accounts } = useMsal();
  const account = accounts[0];

  const getAccessToken = async () => {
    try {
      const request = {
        scopes: [`${process.env.NEXT_PUBLIC_CLIENT_ID}/.default`],
        account: account,
        redirectUri: '/',
      };

      const response = await instance.acquireTokenSilent(request);
      return response.accessToken;
    } catch (error) {
        console.log('error', error)
      if (error instanceof InteractionRequiredAuthError) {
        instance.acquireTokenRedirect(request);
      } else {
        throw error;
      }
    }
  };

  return getAccessToken;
};
```

And just for the sake of the example, one of components which uses the the custom hook which fetches the accessToken from AAD and sending as Authentication header in one if its API calls:

```javascript
import React, { useState, useEffect } from 'react';
import { useMsal } from '@azure/msal-react';

import { useAccessToken } from '@hooks/useToken';

const DeviceTable = () => {
  const getAccessToken = useAccessToken();
  const [regions, setRegions] = useState({});
  const [error, setError] = useState(null);

  useEffect(() => {
    let apiUrl = '';

    const fetchConfigAndData = async () => {
      try {
        const accessToken = await getAccessToken();

        const regionsData = await fetch(`${apiUrl}/api/v1/devices`, {
          headers: {
            'Authorization': `Bearer ${accessToken}`
          }
        }).then(res => res.json());
        setRegions(regionsData);
      } catch (error) {
        setError(error);
      }
    };

    fetchConfigAndData();
  }, []);
```

Keep in mind that i'm not an experienced frontend developer, so the code above might not be the best practice, but it works for me. I'll be happy to hear your feedback and suggestions. I'm mostly available on [Linkedin](https://www.linkedin.com/in/kazaz-or/).


Learn how to integrate Azure AD authentication into your Next.js app using MSAL library for security and user management.

Integrating Azure AD Authentication in Your Next.js App Using MSAL



The common purposes of scheduling Lambda functions is to automate tasks such as nightly data backups, data fetching and processing, or any routine task that needs to run on a scheduled basis.

If you're using AWS as a cloud provider, once of the most common services to schedule your lambdas is EventBridge (formerly known as CloudWatch Events).

To show and example of how to create such thing, we'll use Terraform.

First, lets create the rule itself (eventually it'll be registered in EventBridge):

```hcl
resource "aws_cloudwatch_event_rule" "schedule" {
  name                = "${var.name_prefix}-schedule"
  description         = "Schedule for Updater Lambda Function (ap-vpn-console)"
  schedule_expression = var.schedule_expression
}
```
__name:__ A unique identifier for the rule, using a variable for flexibility.

__description:__ Clear description of what the rule does.

__schedule_expression:__ When the Lambda will be triggered. Use the `schedule_expression` variable to easily change the timing without modifying the code directly.

Just in case you're not familiar with cron expressions, here is an example:

```hcl
variable "schedule_expression" {
  description = "The schedule expression for the lambda function"
  type        = string
  default     = "cron(0 2,10 * * ? *)"
}
```
This cron expression means the Lambda will run at 2:00 AM and 10:00 AM (UTC) every day.

![schedule-rule](/images/eventbridge-lambda-rule.jpeg)


Now let's hook it with our Lambda function:

```hcl
resource "aws_cloudwatch_event_target" "schedule_lambda" {
  rule      = aws_cloudwatch_event_rule.schedule.name
  target_id = "processing_lambda"
  arn       = aws_lambda_function.lambda.arn
}
```

__rule:__ Links the target to the previously defined rule.

__target_id:__ An identifier for the target.

__arn:__ Amazon Resource Name for the Lambda function to execute.


Last thing we might want to do, is to allow EventBridge to invoke the Lambda function by defining its permissions:

```hcl
resource "aws_lambda_permission" "allow_events_bridge_to_run_lambda" {
  statement_id  = "AllowExecutionFromCloudWatch"
  action        = "lambda:InvokeFunction"
  function_name = aws_lambda_function.lambda.function_name
  principal     = "events.amazonaws.com"
}
```

__statement_id:__ A unique identifier for the statement.

__action:__ Specifies the allowed action.

__function_name:__ Links to the Lambda function.

__principal:__ The AWS service that is allowed to perform the action.


Schedule your AWS Lambda tasks using Terraform and AWS EventBridge to automate routine tasks and improve efficiency.

Scheduling Lambdas Using AWS EventBridge and Terraform


Every web developer, either frontend or backend, may have come across this CORS policy violation (Cross-Origin Resource Sharing) error message at least once in their career.

The error itself is actually pretty informative. It basically tells you that the client-side is not one of the "whitelisted" origins to access the data being fetched. This is a security mechanism that browsers implement to prevent malicious users from accessing the data from a different origin.

Let's dive in a little bit.

First, what is CORS exactly? CORS stands for Cross-Origin Resource Sharing, which is a security mechanism that allows/prevents one origin to access a resource from a different origin. This is something that the server has control over to restrict who has access to the resource, how they can access the data, for example, which HTTP methods, HTTP headers, etc are allowed.
At its core, you can treat it as a protocol allowing web applications to request resources from different domains securely. It's a dance of headers and requests, where the server dictates who can access its resources.


__Same Origin Policy vs Cross Origin Resource Sharing__

The Same-Origin Policy (SOP) is a critical security mechanism that restricts web pages from making requests to a different origin than the one that served the web page. CORS, on the other hand, is a tool to relax those restrictions under controlled conditions. It allows servers to specify who can access their assets and how.

__CORS Mechanism__

CORS works by adding new HTTP headers that allow servers to declare which origins are permitted to access the resources. For example, the `Access-Control-Allow-Origin` header can specify an allowed origin, or it can use `*` to allow requests from any origin. However, using `*` in most cases is discouraged for sensitive resources due to security concerns.



Let's take a look at an example using NodeJS & Express:

```javascript
const express = require('express');
const cors = require('cors');
const app = express();

app.use(cors());

// CORS with specific options
const corsOptions = {
  origin: 'https://example.com',
};

app.get('/data', cors(corsOptions), (req, res) => {
  res.json({ message: 'This route is CORS-enabled for an allowed origin.' });
});

app.listen(3000, () => console.log('Server running on port 3000'));
```

Here we're basically using the `cors` middleware that is applied globally to allow Cross-Origin Resource Sharing (CORS) from any origin, enabling client applications from different domains to access the server. Additionally, it showcases a more complex setup where CORS settings are customized for a specific route, allowing requests only from a specified origin and setting specific methods and headers.

Now, let's take a look at another example, but this time using Python & FastAPI:

```python
from fastapi import FastAPI
from fastapi.middleware.cors import CORSMiddleware

app = FastAPI()

# Simple CORS
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],
    allow_credentials=True,
    allow_methods=["*"],
    allow_headers=["*"],
)

# CORS for specific origins
origins = [
    "http://example.com",
]
app.add_middleware(
    CORSMiddleware,
    allow_origins=origins,
    allow_credentials=True,
    allow_methods=["GET"],
    allow_headers=["X-Custom-Header"],
)

@app.get("/data")
async def get_data():
    return {"message": "This route is CORS-enabled for specific origins."}
```

This simple snippet demonstrates two approaches: a global application of CORS allowing all origins, methods, and headers, and a more restrictive approach where CORS is configured for specific origins, methods, and headers on all routes, illustrating how to control access to your API more granularly.

Implementing CORS correctly is a balancing act. Developers must ensure their web applications are accessible to legitimate users and services while protecting against unauthorized access. Understanding CORS is crucial for any developer working on the web, as it directly impacts the security and functionality of web applications.


I can assure you that one of the first issues you'll encounter when testing your newly developed product will be CORS. So what is CORS exactly?

CORS - Introduction For The New FE/BE Developer


Ensuring consistent application performance across multiple platforms is a cornerstone of quality software delivery. In this post, I'll share my approach for using GitHub Actions to automate testing across a variety of platforms, drawing from a real use case at my workplace.

Our solution utilizes GitHub Actions, a CI/CD service that enables automation of build, test, and deployment workflows directly within GitHub. The highlight of the approach is the dynamic matrix strategy, which handles both scheduled runs and on-demand tests across specified platforms.

__Scheduled and On-demand Testing__

In this example, the workflow is being triggered automatically at 22:00 every day for nightly tests. Additionally, we enabled manual triggers for specific platforms, allowing for targeted testing as needed. This flexibility is crucial for maintaining a fast-paced development cycle without compromising on quality.

```yaml
on:
  schedule:
    - cron: '0 22 * * *'
  workflow_dispatch:
    inputs:
      platform:
        description: 'Choose platform to run the test on'
        required: true
        type: choice
        options:
          - webos
          - tizen
          - playstation4
          - playstation5
          - xbox
```

This configuration leverages the `schedule` and `workflow_dispatch` events in GitHub Actions. The `cron` syntax schedules automated test runs, while `workflow_dispatch` allows for manual execution with platform-specific parameters.

__Dynamic Test Matrix Configuration__

The core of our workflow dynamically adjusts the test matrix based on the context of the trigger—whether it's a scheduled job covering all platforms or a manual job focusing on a specific platform.

```yaml
jobs:
  setup-test:
    runs-on: ubuntu-latest
    outputs:
      platform: ${{ steps.set-matrix.outputs.platform }}
    steps:
      - id: set-matrix
        run: |
          if [ "${{ github.event_name }}" = "schedule" ]; then
            echo 'platform=["webos", "tizen", "playstation4", "playstation5", "xbox"]' >> $GITHUB_ENV
          else
            echo 'platform=["${{ github.event.inputs.platform }}"]' >> $GITHUB_ENV
```

In this snippet, we employ conditional logic to populate the platform variable differently based on the trigger type. For scheduled runs, we test across all platforms, while manual triggers allow for focused testing on a selected platform. This strategy ensures that resources are allocated efficiently, focusing our testing efforts where they are most needed.
Of course, you could always do that with an external script or with a composite action, but this is a simple and effective way to achieve the same result.

__Executing the Tests with Dynamic Configuration__

Our approach to executing tests in this workflow benefits significantly from the dynamic nature of GitHub Actions, especially when it comes to handling multiple platforms which can be quite different from each other. This flexibility is further extended into our application's `package.json` file, where we define specific scripts for our testing needs. The `package.json` plays a crucial role in integrating the GitHub environment variables directly into our test execution process.

Without getting into the tests code, you can imagine that each platform has its own specific tests and configurations, and that's why we need to run the tests separately for each platform. This is where the dynamic matrix comes into play.


```yaml
- name: Run tests
  working-directory: ./src/lr-launcher-e2e
  env:
    npm_config_env: ${{ matrix.platform }}
  run: npm test
```

Here, the `npm test` command is executed within the context of each platform specified by the dynamic matrix. This ensures that our E2E tests are relevant and efficient, automatically adapting to the complexities of multi-platform support.

Here's a look at the relevant part of our `package.json` file:

```json
{
  "name": "lr-launcher",
  "version": "1.0.0",
  "scripts": {
    "pre-test": "node ./utils/setupTest.js --",
    "test": "mocha \"tests/*.test.js\" \"tests/$npm_config_env/*.test.js\" --no-timeouts --retries 1 --exit"
  },
  "dependencies": {
    "axios": "^1.6.2",
    "mocha": "^10.2.0",
  }
}
```
This script utilizes the `npm_config_env` environment variable, which we set dynamically based on the selected platform in our GitHub Actions workflow. By incorporating `$npm_config_env` into the mocha command, we ensure that the test runner picks up not only the general tests from tests/*.test.js but also platform-specific tests located in directories named after each platform (e.g., tests/webos/*.test.js).

This setup allows us to maintain a clear and organized test structure where platform-agnostic tests are separated from those that are platform-specific. It ensures that when our GitHub Actions workflow runs, it only executes the relevant tests for the specified platform, making our testing process both efficient and comprehensive.


Automate cross-platform testing with GitHub Actions, using dynamic matrices for efficient, targeted tests.

GitHub Actions for Dynamic Cross-Platform Testing


Makefiles are powerful tools in a developer's arsenal, capable of significantly improving efficiency and consistency in the build process. By understanding and utilizing Makefiles for Docker and Terraform, developers can streamline their workflows, reduce repetitive tasks, and focus more on the creative aspects of software development.

In this article, we'll explore the basics of Makefiles and how they can be used to automate the build process with examples of Docker and Terraform commands usage.

### What is a Makefile?

Incorporating a Makefile into your project can greatly streamline various development tasks, such as managing dependencies, running tests, building documentation,formatting code, performing static analysis, build/compile/transpile, cleaning up temporary files and more.

The flexibility of Makefiles allows you to automate routine processes in a structured and efficient manner. Here's a more detailed look at how you can leverage Makefiles in your projects:


### Basic Structure of a Makefile

A Makefile typically consists of targets, prerequisites, and recipes. Targets represent the goals you want to achieve, which could be actions like running your app or installing dependencies. Prerequisites are files or other targets needed before a target can be executed. Recipes are shell commands that make will execute.

For instance, you might have a `run` target to execute your Python application, a `setup` target for installing dependencies listed in `requirements.txt`, and a `clean` target for removing Python bytecode files or the `__pycache__` directory.

### Advanced Techniques

__Default Goals and Help Messages:__ Setting a default goal, like `.DEFAULT_GOAL := help`, allows you to display a helpful message when make is run without a target.

__Virtual Environments:__ Integrating virtual environments in your Makefile ensures that the right Python environment and dependencies are used. This can be crucial in projects with specific version requirements or multiple dependencies.

__Injecting Paths into `PYTHONPATH:`__ This advanced trick allows Python to search for packages in specified file system paths without needing to install them, which can be particularly useful in projects with heavy dependencies or multiple branches.


### Some Practical Examples

__Running Tests with Coverage:__ You can create a coverage target to run tests with coverage, specifying the commands for running the tests and generating a coverage report.

__Linting and Static Analysis:__ A lint target can be set up to run various linting and static analysis tools like flake8, pylint, and mypy on your code.

__Task Dependencies and Parameters:__ Makefiles allow you to specify dependencies between tasks. For example, a test target might depend on a lint target. You can also pass parameters to tasks, like specifying an IP and port for a serve task.

__Makefile for Docker Commands:__ 

By leveraging Makefiles in your Python projects, you not only save time but also create a more robust and maintainable development environment. These examples and advanced features illustrate just how versatile and powerful Makefiles can be in automating and streamlining your Python development workflow.

```makefile
export TOP := $(shell git rev-parse --show-toplevel)
export IMAGE_NAME := my-docker-image
export CONTAINER_NAME := my-container-image

build:
	docker build --build-arg JFROG_USERNAME=${JFROG_USERNAME} --build-arg JFROG_ARTIFACTORY_TOKEN=${JFROG_ARTIFACTORY_TOKEN} -t $(IMAGE_NAME) .

run:
	$(TOP)/scripts/run_docker.sh &

exec:
	docker exec -it $(CONTAINER_NAME) /bin/sh

delete:
	docker stop $(CONTAINER_NAME)
	docker rm $(CONTAINER_NAME)
```
In this example the `build` command creates a Docker image with build arguments (`make build`).

The `run` command runs a script to start the container in the background (`make run`). It runs a bash script that starts the container in the background and saves the container ID in a file.

The `exec` provides an interactive shell within the container for debugging proposes (`make exec`).

The `delete` stops and removes the container (`make delete`).

__Makefile for Terraform Commands:__

Terraform, an infrastructure as code software tool, also benefits from Makefiles, its commands can become quite complex. Here's an example on why it is useful to use Makefiles for Terraform:

```makefile
account := dev
namespace ?= $(shell echo $(USER) | awk '{print tolower($0)}')
service ?= $(shell basename `git rev-parse --show-toplevel`)

ifeq ($(account), dev)
    AWS_PROFILE := 123456
else ifeq ($(account), stage)
    AWS_PROFILE := 654321
else
    $(error Invalid account specified: $(account))
endif

init:
	terraform init -reconfigure \
		-backend-config=config/$(account)/backend.tfvars -backend-config=key=services/$(namespace)/$(service).tfstate

plan:
	terraform plan -out /tmp/$(service).tfplan \
		-var-file=config/$(account)/terraform.tfvars -var-file=config/$(account)/service.tfvars \
		-var "namespace=$(namespace)" -var "service_name=$(service)"

apply:
	terraform apply /tmp/$(service).tfplan

validate:
	@terraform validate

destroy:
	terraform destroy \
		-var-file=config/$(account)/terraform.tfvars -var-file=config/$(account)/service.tfvars \
		-var "namespace=$(namespace)" -var "service_name=$(service)"
```

This Makefile automates various Terraform commands like `init` which initializes a new or existing Terraform configuration (`make init`).
This command is particularly used to initialize the working directory containing Terraform configuration files, with -reconfigure to force re-initialization. It specifies backend configuration variables and the state file location.

The `plan` command creates an execution plan. This command creates a Terraform plan and outputs it to a temporary file. It specifies variable files and sets additional variables like namespace and service_name (`make plan`).

The `apply` command applies the changes required to reach the desired state of the configuration (`make apply`).

The `validate` command is used to validate the syntax and configuration of the Terraform files (`make validate`).

The `destroy` command is used to destroy all resources managed by the current Terraform configuration (`make destroy`).

In conclusion, Makefiles stand as a fundamental and powerful tool in software development, offering a versatile approach to automating and streamlining various aspects of the build process. Whether you're working with Docker containers or managing infrastructure with Terraform, Makefiles bring a level of efficiency and consistency that can significantly enhance your workflow. By effectively leveraging Makefiles, developers not only save valuable time but also ensure a more robust and maintainable development process, making them an essential component in any modern software project.


Makefiles are a cornerstone tool in the software development process, particularly useful for streamlining and automating the build process.

Welcome to
Kazi's Dev Blog

Newest Blog Posts(See All)

Handling CI/CD in a Mono Repo With Multiple Python Packages

Lab as a Service in DAZN

S3 Bucket Redirect URL With Terraform

Integrating Azure AD Authentication in Your Next.js App Using MSAL

Scheduling Lambdas Using AWS EventBridge and Terraform

CORS - Introduction For The New FE/BE Developer

GitHub Actions for Dynamic Cross-Platform Testing

Why Makefile is One of My Essentials Tools in Every Software Project

Explore More Blog Posts

Welcome to Kazi's Dev Blog

Newest Blog Posts(See All)

Handling CI/CD in a Mono Repo With Multiple Python Packages

Lab as a Service in DAZN

S3 Bucket Redirect URL With Terraform

Integrating Azure AD Authentication in Your Next.js App Using MSAL

Scheduling Lambdas Using AWS EventBridge and Terraform

CORS - Introduction For The New FE/BE Developer

GitHub Actions for Dynamic Cross-Platform Testing

Why Makefile is One of My Essentials Tools in Every Software Project

Explore More Blog Posts

Welcome to
Kazi's Dev Blog