1.Planning poker

Planning poker is a collaborative estimation technique that uses a deck of cards with values (e.g., Fibonacci sequence) to estimate the complexity of user stories. Team members take turns presenting their estimates, and discussions continue until a consensus is reached. It encourages team participation and minimizes anchoring biases.

How to do?

The Agile team, which typically includes developers, testers, and other relevant members, gathers for an estimation session. The product backlog or a list of user stories or tasks to be estimated is ready for discussion. Each participant should have a deck of Planning Poker cards or access to a digital tool designed for Planning Poker. Cards often have values like the Fibonacci sequence (1, 2, 3, 5, 8, 13, etc.), while digital tools display these values for selection.

A moderator or facilitator, often a Scrum Master or Product Owner, leads the session. Their role is to guide the discussion, ensure everyone participates, and keep the process on track.

The moderator selects one user story or task from the backlog for estimation and presents it to the team. The item's description and acceptance criteria may also be shared.

Each team member individually selects a Planning Poker card that represents their estimate of the effort or complexity of the item. They do this privately without revealing their choice to others.

Once everyone has selected a card, the team members simultaneously reveal their chosen cards to the group. If using physical cards, they can reveal them by flipping them face-up at the same time. If using digital tools, they press a button to reveal their estimates simultaneously.

If there is a wide range of estimates, team members briefly discuss the reasoning behind their choices. This discussion helps the team reach a common understanding of the work item. After discussion, team members repeat the estimation process, selecting new cards if their initial estimates have changed. The process of discussion and card selection is repeated until a consensus is reached, or until a predefined time limit is reached.

Once a consensus estimate is reached, the final estimate is recorded and associated with the user story or task in the backlog. This estimate is used for planning and prioritization.

Why the Fibonacci sequence?

The Fibonacci sequence is a non-linear scale, which means that the gap between successive numbers increases as you move up the sequence. This reflects the reality that as work items become more complex or larger, it becomes increasingly challenging to estimate their precise effort or duration. In Agile, the focus is on relative sizing and understanding that a task that is twice as large as another might take significantly more effort.

Using linear scales (e.g., 1, 2, 3, 4, 5) can give a false sense of precision when estimating work. It's difficult for humans to consistently and accurately estimate effort in linear units, such as hours. The Fibonacci sequence acknowledges this uncertainty and encourages teams to think in terms of broader categories.

Alternatives

While the Fibonacci sequence is a widely used scale in Agile estimation, there are several alternatives that teams can consider depending on their preferences and specific needs. These alternative estimation scales include:

1. T-shirt Sizes: Instead of numeric values, teams assign T-shirt sizes (e.g., XS, S, M, L, XL) to represent the relative size and complexity of user stories or tasks. This approach is easy to understand and is useful for high-level, coarse-grained estimation.

2. Custom Scales: Teams can create their custom estimation scales based on their specific context and preferences. For example, a team might create a scale that includes values like "Trivial," "Simple," "Moderate," "Complex," and "Very Complex" to reflect the nature of their work.

Tools for Planning Poker

There are several free Planning Poker tools and applications available that teams can use to facilitate Agile estimation and collaborative planning sessions. These tools often offer features like virtual card decks, real-time collaboration, and integration with project management or Agile tools. Here is some of them I tried:

PlanITpoker: https://www.planitpoker.com/

Pointing Poker: https://www.pointingpoker.com/

Scrumvee: https://www.scrumvee.com/

2.Dot Voting

Dot Voting is an Agile estimation technique suitable for sprint planning, especially when dealing with a relatively small number of items in the Sprint Backlog. It offers a collaborative way for team members to collectively prioritize and allocate effort estimates to user stories or tasks.

Before the Dot Voting session, gather small dot stickers, each color-coded to represent different levels of estimated effort. For example, you can use green for Small (S), blue for Medium (M), orange for Large (L), and red for Extra Large (XL).

Write down the user stories or tasks to be estimated on separate pieces of paper or cards. Place these items on a table or display them on a wall within the team's workspace. Ensure that everyone can easily see and access the items.

Team members are given a set number of dot stickers in each color category corresponding to the estimated effort levels. For instance, each team member might receive a certain number of green, blue, orange, and red stickers.

Team members physically walk around the table or the wall display and assess the items. They then add their colored dot stickers to the items they believe should be prioritized or where they estimate the effort is most needed. Team members can distribute their stickers freely among the items based on their judgments.

Once all team members have allocated their stickers, you can observe which items have accumulated the most dots of each color. The items with more dots indicate higher levels of prioritization or estimated effort.

Depending on the outcomes and the team's preference, you can facilitate a brief discussion to address any significant differences in estimation. This discussion allows team members to explain their rationale and reach a consensus on prioritization or effort allocation.

3.The Bucket System

The Bucket System is an Agile estimation technique used to categorize and prioritize tasks, user stories, or backlog items based on their perceived size, complexity, or effort. It provides a simple and effective way for Agile teams to quickly group work items into predefined buckets or categories, allowing for easier prioritization and allocation of resources.

Before starting the Bucket System estimation process, gather the team, including developers, testers, and relevant stakeholders, for a collaborative estimation session.

Define the criteria for categorizing items into buckets. These criteria can vary depending on the team's context but often include factors like complexity, effort, risk, or size. Decide on the number and names of buckets that will be used for categorization. Common bucket names include "Small," "Medium," "Large," and "Extra Large," but you can customize them to match your team's needs.

Present a list of user stories, tasks, or backlog items that need to be estimated. These items should be clearly defined, and their descriptions and acceptance criteria should be readily available to the team.

Begin the categorization process by discussing each item one by one. The team members collectively decide which bucket best represents the size, complexity, or effort required to complete the item.

Place each item into the appropriate bucket based on the consensus reached during the discussion. It's essential to have the entire team agree on the categorization for each item.

After categorizing all the items, the team can prioritize the work based on the bucket assignments. Typically, items in smaller buckets are tackled first, followed by those in larger buckets, but this can vary depending on project priorities.

It's important to revisit the Bucket System regularly, especially as new information becomes available or as the team gains a better understanding of the work. Refinement and iteration ensure that items are continuously evaluated and correctly categorized.

Large/Uncertain/Small

The "Large/Uncertain/Small" method is a variation of the Bucket System used in Agile estimation. It categorizes tasks, user stories, or backlog items into three buckets: Large (high effort or uncertainty), Uncertain (moderate effort or uncertainty), and Small (low effort or certainty). This approach helps Agile teams quickly prioritize and allocate work items based on their perceived size and uncertainty, facilitating efficient planning and resource allocation.

4.Expert Judgment

Expert Judgment is an Agile estimation technique that relies on the expertise and insights of individuals or subject matter experts within the team to assess the effort, complexity, or duration of tasks, user stories, or project components. It is a qualitative approach that leverages the knowledge and experience of team members to provide informed estimates based on their understanding of the work.

Steps:

1. Ensure that the Agile team, including developers, testers, and relevant stakeholders, is present for the estimation session. The participation of individuals with diverse expertise is valuable.

2. Introduce the tasks, user stories, or items that need to be estimated. Provide a clear description of each item, including acceptance criteria and any relevant background information.

3. Encourage team members to share their expert judgments regarding the effort, complexity, or duration of the items under consideration. Each team member provides their estimation based on their individual expertise.

4. Facilitate a discussion among team members to address any questions or concerns regarding the items being estimated. This discussion allows experts to share their insights and rationale for their estimations.

5. After individual estimations and discussions, work toward reaching a consensus estimate for each item. This consensus may involve adjusting estimations based on the input and expertise of the team members.

Conclusion

In summary, Agile effort estimation techniques are essential tools for Agile teams to plan and manage their work effectively. These techniques enable teams to assign relative effort, prioritize tasks, and make informed decisions based on collective input. Some popular Agile estimation techniques include Planning Poker, Dot Voting, the Bucket System, and Expert Judgment.

• Planning Poker promotes collaborative estimation through card-based voting and discussions, fostering alignment and consensus within the team.

• Dot Voting is a visual technique for prioritizing tasks based on team members' preferences, encouraging participation and transparency.

• The Bucket System categorizes work items into predefined buckets, simplifying prioritization and resource allocation.

• Expert Judgment leverages the expertise of team members to provide informed estimates, particularly valuable for complex or novel tasks.

These Agile estimation techniques, along with others, serve to enhance Agile project planning, promote collaboration, and enable teams to adapt and deliver value effectively. By selecting the most suitable method for their context, Agile teams can refine their estimations, prioritize work, and achieve successful project outcomes.

There are various other Agile estimation methods beyond the ones discussed here as well. These methods may include custom scales, affinity mapping, reference stories, and more. Agile teams often choose the estimation approach that best aligns with their specific context, goals, and team dynamics. The key is to select the method that facilitates effective planning, prioritization, and collaboration within the Agile framework.

A while ago I had a chat with buddies about choosing the "right" AWS region for their solution. The target users were from Azerbaijan and some people suggested that they should use the Bahrain region because it is the closest.

This is how I got the idea for this blog article.

Of course, when we say the "right" region there are many factors such as speed, price, regulations etc. In this blog, we will focus on speed only.

One crucial factor to consider is network hop distance, which directly affects latency and data transfer speeds.

Hop distance?

When it comes to selecting the right AWS region for your cloud resources, the first idea that comes to mind is to opt for the region that's physically closest to your location. It seems like a logical choice; after all, shorter physical distances should mean faster connections, right? Well, not necessarily.

What many people fail to realize is that the internet is a complex web of interconnected networks, and data doesn't always take the most direct route. Instead, it hops through a series of routers and switches, each introducing a slight delay known as latency. This is where the concept of network hop distance comes into play.

Network hop distance is the number of network hops (or routers) data packets that must traverse between the source and destination. Network hop distance is a more accurate measure of network performance. Lower hop distance typically results in lower latency, faster data transfers, and an improved user experience, regardless of physical distance.

So how to choose the AWS region?

To determine the AWS region that offers the lowest network hop distance for your users, follow these steps:

1. Identify Your User Base

Start by identifying the geographic locations of your primary user base, just as you did in the scenario with friends.

2. Locate AWS Regions

AWS provides data centers, known as regions, across the globe. Each region consists of multiple Availability Zones, which are essentially separate data centers within the same geographic area. AWS regions are located in North America, South America, Europe, Asia, Australia, and the Middle East. Visit the AWS Global Infrastructure page to see a list of AWS regions and their locations.

3. Measure Network Hop Distance

You can use network diagnostic tools like traceroute or ping to find the hop distance between your users and various AWS regions, regardless of physical proximity.

Traceroute: Open your command prompt or terminal and run the traceroute command followed by the IP address or domain name of the AWS region. For example:

•   traceroute ec2.us-east-1.amazonaws.com
  

This will display a list of routers (hops) and their round-trip times (latency) between your location and the AWS region.

If you want to see something visual, just for consideration you can visit https://www.submarinecablemap.com/. This web page has an interactive map of cables by most of the companies. However, I do not recommend you to rely on it as it will not be accurate.

Conclusion

Choosing the closest AWS region based on network hop distance is a fundamental step in optimizing the performance of your cloud-based applications and services. By identifying your user base, locating AWS regions, and measuring hop distances, you can make an informed decision that minimizes latency and provides the best possible user experience.

Remember that network conditions can change over time, so it's a good practice to periodically reevaluate your AWS region choice to ensure optimal performance for your users. With the right region selection, you can harness the full potential of AWS and deliver a seamless and responsive online experience.

In today's fast-paced digital landscape, having a reliable and scalable platform to host your web applications is crucial. Azure Static Web Apps, offered by Microsoft Azure, is a powerful solution for deploying static websites and single-page applications with ease.

In this blog post, we'll walk you through the process of deploying a static Next.js app to Azure Static Web Apps using GitHub. You'll learn how to set up your environment, configure Azure, automate the deployment process with GitHub Actions, and finally, enjoy the benefits of a highly available and globally distributed web application.

So, whether you're a seasoned developer looking to streamline your deployment workflow or a newcomer eager to explore modern web development practices, this guide is for you. Let's dive in and discover how to harness the power of Azure Static Web Apps for hosting your Next.js projects.

Create NextJS application

First of all, we need a sample NextJS application. This can be your existing NextJS application too. In this tutorial, we will use a sample from Vercel based on the tutorial [1].

Type the following command in your terminal to create a sample NextJS application in nextjs-blog directory.

npx create-next-app@latest nextjs-blog --use-npm --example "https://github.com/vercel/next-learn/tree/main/basics/learn-starter"

After the app is created test it to make sure it works.

cd nextjs-blog
npm install
npm run dev

Go to your browser and check the URL (http://localhost:3000).

As we want to deploy it to Azure Static Web Apps we need to do some tricks, in particular, we want to export the NextJS app statically.

Create a file next.config.js in the home folder of the application with the following content:

module.exports = {
    images: {
        unoptimized: true
    },
    trailingSlash: true,
    output: 'export'
}

Now, let's try to build

npm run build

If successful you will see a newly created directory /out. This directory contains static HTML/JS/CSS files compiled from your NextJS app.

Hooray, we are ready to deploy it to Azure using the Static Web Apps service.

Set up the GitHub repository

Create a GitHub repository and upload your NextJS application to that repository.

Deploy to Static Web Apps

In this stage, we want to explore how Static Web Apps work and do a basic setup. In the next phase, we will refine our pipeline.

In this tutorial, I will follow the steps from the tutorial published on Microsoft's web page [2].

1. Go to the Azure portal

2. Search for Static Web Apps

3. Click Create

Enter the necessary data in the form and Sign in with GitHub:

Follow the instructions and workflow file will be created automatically in your repository with the following content (we will edit it in the next section):

name: Azure Static Web Apps CI/CD

on:
  push:
    branches:
      - main
  pull_request:
    types: [opened, synchronize, reopened, closed]
    branches:
      - main

jobs:
  build_and_deploy_job:
    if: github.event_name == 'push' || (github.event_name == 'pull_request' && github.event.action != 'closed')
    runs-on: ubuntu-latest
    name: Build and Deploy Job
    steps:
      - uses: actions/checkout@v3
        with:
          submodules: true
      - name: Build And Deploy
        id: builddeploy
        uses: Azure/static-web-apps-deploy@v1
        with:
          azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN_<GENERATED_HOSTNAME> }}
          repo_token: ${{ secrets.GITHUB_TOKEN }} # Used for Github integrations (i.e. PR comments)
          action: "upload"
          ###### Repository/Build Configurations - These values can be configured to match your app requirements. ######
          # For more information regarding Static Web App workflow configurations, please visit: https://aka.ms/swaworkflowconfig
          app_location: "/" # App source code path
          api_location: "" # Api source code path - optional
          output_location: "out" # Built app content directory - optional
          ###### End of Repository/Build Configurations ######

  close_pull_request_job:
    if: github.event_name == 'pull_request' && github.event.action == 'closed'
    runs-on: ubuntu-latest
    name: Close Pull Request Job
    steps:
      - name: Close Pull Request
        id: closepullrequest
        uses: Azure/static-web-apps-deploy@v1
        with:
          azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN_<GENERATED_HOSTNAME> }}
          action: "close"

The basic pipeline is set. Whenever you raise a pull request in your repository GitHub Action will be triggered and deploy your web app into Azure.

The wizard in the previous step created a workflow file and pushed it into your repository. And also necessary secrets (AZURE_STATIC_WEB_APPS_API_TOKEN_<GENERATED_HOSTNAME>) has been created for you to integrate GitHub with Azure. You can see it in the settings of your GitHub repository.

When PR is created the workflow will be triggered and after a while, the endpoint URL will be seen in the comments section:

Multiple staged deployment

When your webpage goes to production and gains an audience you won't publish any experimental untested code into production. On the other hand, you still need some environment where you want to see the output of the latest codes before deciding to publish. Here the idea of multi-staged deployment comes.

The diagram below explains the high-level idea:

Now, let's implement it. At first, we will edit our workflow file and we will trigger deployment on PR only for the development environment (we will call it preview).

Magically, when you raise a PR Azure Static Web Apps (actually Azure scripts that GHA uses) and create a temporary environment. The URL will be published as a comment in the PR. Therefore, the preview environment is done for us out of the box.

Now we want a beta environment. Any code that is merged into the main branch will trigger an action to deploy it to a beta environment without approval. To make things easier we will use an already existing environment as a preview of and beta. Because Azure already did all the magic for us.

Now it is my turn to create a production environment. We go to Azure portal -> Static Web Apps -> Create.

This time under the source we chose Other:

1. After the app is created go to the Overview page and click "Manage deployment token":

1. Copy the token.

2. Then go to the GitHub repository. Click Settings.

3. Secrets and Variables -> Actions

   

4. New repository secret.

5. Paste the token and give a name. In my example the name was AZURE_STATIC_WEB_APPS_API_TOKEN_PRODUCTION

Now it is time to edit our workflow file. Here is my final workflow file:

name: Azure Static Web Apps CI/CD

on:
  push:
    branches:
      - main
  pull_request:
    types: [opened, synchronize, reopened, closed]
    branches:
      - main

jobs:
  build_and_deploy_job:
    needs: [build_and_deploy_to_beta]
    if: github.event_name == 'push'
    runs-on: ubuntu-latest
    name: Deploy to PROD
    environment:
      name: production
    steps:
      - uses: actions/checkout@v3
        with:
          submodules: true
      - name: Build And Deploy
        id: builddeploy
        uses: Azure/static-web-apps-deploy@v1
        with:
          azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN_PRODUCTION }}
          repo_token: ${{ secrets.GITHUB_TOKEN }} # Used for Github integrations (i.e. PR comments)
          action: "upload"
          ###### Repository/Build Configurations - These values can be configured to match your app requirements. ######
          # For more information regarding Static Web App workflow configurations, please visit: https://aka.ms/swaworkflowconfig
          app_location: "/" # App source code path
          api_location: "" # Api source code path - optional
          output_location: "out" # Built app content directory - optional
          ###### End of Repository/Build Configurations ######
        env: # Add environment variables here
          IS_STATIC_EXPORT: true      

  build_and_deploy_to_dev:
    if: (github.event_name == 'pull_request' && github.event.action != 'closed')
    runs-on: ubuntu-latest
    name: Deploy to DEV
    environment:
      name: development
    steps:
      - uses: actions/checkout@v3
        with:
          submodules: true
      - name: Build And Deploy
        id: builddeploy
        uses: Azure/static-web-apps-deploy@v1
        with:
          azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN_LEMON_ROCK_00E996803 }}
          repo_token: ${{ secrets.GITHUB_TOKEN }} # Used for Github integrations (i.e. PR comments)
          action: "upload"
          ###### Repository/Build Configurations - These values can be configured to match your app requirements. ######
          # For more information regarding Static Web App workflow configurations, please visit: https://aka.ms/swaworkflowconfig
          app_location: "/" # App source code path
          api_location: "" # Api source code path - optional
          output_location: "out" # Built app content directory - optional
          ###### End of Repository/Build Configurations ######
        env: # Add environment variables here
          IS_STATIC_EXPORT: true        
      - name: Comment URL
        uses: actions/github-script@v6
        env:
          STATIC_WEB_APP_URL: ${{ steps.builddeploy.outputs.static_web_app_url }}
        with:
          script: |
            console.log(JSON.stringify(process.env))
            github.rest.issues.createComment({
                issue_number: context.issue.number,
                owner: context.repo.owner,
                repo: context.repo.repo,
                body: '👋 Eşq olsun!\nWeb sayt müvəqqəti olaraq bu ünvanda yerləşdirildi: ' + process.env["STATIC_WEB_APP_URL"]
              })

  build_and_deploy_to_beta:
    if: github.event_name == 'push'
    runs-on: ubuntu-latest
    name: Deploy to BETA
    environment:
      name: development
    steps:
      - uses: actions/checkout@v3
        with:
          submodules: true
      - name: Build And Deploy
        id: builddeploy
        uses: Azure/static-web-apps-deploy@v1
        with:
          azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN_LEMON_ROCK_00E996803 }}
          repo_token: ${{ secrets.GITHUB_TOKEN }} # Used for Github integrations (i.e. PR comments)
          action: "upload"
          ###### Repository/Build Configurations - These values can be configured to match your app requirements. ######
          # For more information regarding Static Web App workflow configurations, please visit: https://aka.ms/swaworkflowconfig
          app_location: "/" # App source code path
          api_location: "" # Api source code path - optional
          output_location: "out" # Built app content directory - optional
          ###### End of Repository/Build Configurations ######
        env: # Add environment variables here
          IS_STATIC_EXPORT: true     

  close_pull_request_job:
    if: github.event_name == 'pull_request' && github.event.action == 'closed'
    runs-on: ubuntu-latest
    name: Close Pull Request Job
    steps:
      - name: Close Pull Request
        id: closepullrequest
        uses: Azure/static-web-apps-deploy@v1
        with:
          azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN_LEMON_ROCK_00E996803 }}
          action: "close"

I have three jobs:

• build_and_deploy_to_dev - a job to deploy to the preview environment.

• build_and_deploy_to_beta - a job to deploy to the beta

• build_and_deploy_job - a job to deploy to the production

To demonstrate some features I created an environment variable STATIC_WEB_APP_URL in build_and_deploy_to_dev job. This variable will contain content from the output of the previous step [3][4]. The next step will use this environment variable to put a comment in PR [5].

Another important point is we need an approval mechanism for production deployment. To achieve this:

1. In GitHub go to Settings.

2. Environment -> New Environment

3. Environment name: production (because in workflow file in build_and_deploy_job we used the same name under environment attribute.

4. Create

5. Now you can add reviewers.

Done :)

Conclusion

Deploying a Next.js application to Azure Static Web Apps through GitHub Actions provides you with a robust and efficient workflow. It enables you to focus on what matters most—building amazing web experiences—while automation takes care of the deployment process.

As you've learned in this guide, Azure Static Web Apps offers numerous advantages, including scalability, global availability, and effortless integration with your GitHub repositories. With a simple push to your main branch, your changes are automatically deployed to the Azure cloud without worrying about infrastructure management. Azure Static Web Apps and GitHub Actions give you the tools you need to succeed in this environment.

We hope this guide has been valuable in your journey towards efficient Next.js deployments on Azure. Now, go ahead and leverage this newfound knowledge to take your web applications to the next level. Happy coding!

References

1. https://nextjs.org/learn/basics/create-nextjs-app

2. https://learn.microsoft.com/en-us/azure/static-web-apps/getting-started?tabs=vanilla-javascript

3. https://learn.microsoft.com/en-us/azure/static-web-apps/review-publish-pull-requests

4. https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idoutputs

5. https://github.com/actions/github-script#comment-on-an-issue