Forem: Brian Neville-O'Neill

SonarQube vs Fortify

Brian Neville-O'Neill — Wed, 06 Dec 2023 17:31:50 +0000

SonarSource SonarQube and OpenText Fortify are popular software security and code analysis tools. In this article, we will focus on the following:

SonarQube and Fortify’s features, capabilities, and functionalities.
A comparison between SonarQube and Microfocus Fortify

SonarQube

Sonarqube is a platform used for continuous code inspection and static code analysis. You can use it early in your software development cycle to identify and address code issues. It helps you improve your code quality and reduce build failure rates.

SonarQube has a lower barrier for fast use because it has a user-friendly interface, community support, and easy setup.

SonarQube features

Let’s take a deep dive into the features of SonarQube:

*Code coverage and Testing: * It integrates with many popular testing frameworks and tools that help identify what part of your code hasn’t been tested. It helps with an extensive range by highlighting areas that need test cases.
Code Quality Analysis: SonarQube analyzes code according to predefined standards and alerts you when your code doesn’t meet these standards or doesn’t meet some of the rules. It checks for code quality, like code smells, bugs, and vulnerabilities.
Complex Analysis Of Code: SonarQube analyses your code and lets you know the part of your code that might be hard to maintain or understand. This insight can make your complex code more readable and easily understood.
CI/CD Integration and Reporting: SonarQube integrates with different Continuous Integration and Continuous Delivery (CI/CD) tools, and you can easily add them to your development pipeline. It provides you with centralized reporting that allows you to make data-driven decisions that can improve your software development process.

SonarQube benefits

There are several strengths you enjoy when you use SonarQube, and they are:

Great support for many programming languages
Interactive community support
A detailed set of rules for code quality and detection
It is user-friendly and easy to use
You can integrate with popular CI/CD tools

SonarQube limitations

Despite the benefits you might enjoy when you use SonarQube in your development process, there are certain limitations you should be aware of. They are:

There is limited support for particular programming languages
It lacks advanced code security features
False positives in security vulnerabilities

Fortify

Fortify helps you identify and remedy security vulnerabilities in your software development process. You get a comprehensive approach during your development process with software composition analysis (SCA), dynamic application security testing (DAST), and static application security testing (SAST) it integrates.

Using these features, you can detect vulnerabilities early on and fix them before deploying your application. It supports programming languages from Apex, Java, and others.

Fortify features

Let’s dive into the features of Microfocus Fortify:

Advanced Security Testing: Suppose you use Fortify for your software development process. In that case, you enjoy advanced code security testing that would help your overall efforts because it enables you to understand the issues or potential threats better and can help you address these critical bottlenecks. Using Fortify means picking up problems you might miss using other tools.
Static Code Analysis: Fortify analyses for code structure and logic, which helps identify coding flaws in your source code. Fortify checks your code against predefined rules and notifies you of an issue, allowing you to fix your code before deploying. In addition, Fortify lets you set your own rules and policies based on your software development requirements.
Integration with Build Sytems: Fortify integrates with other build systems and CI/CD pipelines. It allows you to implement security testing as an essential part of your software development process by allowing you to incorporate security testing into existing workflows.

Fortify benefits

There are several benefits of Fortify, and they are:

It allows customizable rules and standards for static code analysis
It has comprehensive security code testing capabilities
It uses advanced vulnerability testing techniques and methods
Easy integration with development environments and CI/CD tools

Fortify limitations

Here are several limitations you have when using Fortify:

It takes a lot of work to set up and a steep learning curve.
Compared to SonarQube, it needs more language support.
It is expensive for enterprise-level usage.

Comparison: SonarQube vs Fortify

There are some differences when you use both tools for your software development process. However, you must know their weakness and strengths to help you make an ideal and better decision.

SonarQube beats Fortify because it has the best-suited features regarding quality code analysis. When you use SonarQube for software development builds, you can get comments from code coverage measurement, a predefined rules-based analysis, complexity analysis, and code duplication detection.
Fortify beats SonarQube regarding security vulnerabilities because it is more suited for this purpose. Fortify offers you in-depth reporting, customizable rules, and data flow analysis. It is specifically designed to deal with security issues in your code.
In terms of integration with CI/CD tools and development workflows, SonarQube and Fortify offer a seamless workaround for developers. They provide detailed reporting for coding and security vulnerabilities to aid your development process.
Regarding operating costs, SonarQube is less expensive than Fortify for enterprise purposes.

Conclusion

Your choice of software for your development process should depend on your project needs, requirements, and available capital for operation. In the article, we looked at the features of both, their benefits, and the limitations you would face when you use them. Furthermore, by comparing both, you can reach a conclusion for which to use when appropriate, assuming it meets your needs.

Aviator: Automate your cumbersome processes

Aviator automates tedious developer workflows by managing git Pull Requests (PRs) and continuous integration test (CI) runs to help your team avoid broken builds, streamline cumbersome merge processes, manage cross-PR dependencies, and handle flaky tests while maintaining their security compliance.

There are 4 key components to Aviator:

MergeQueue – an automated queue that manages the merging workflow for your GitHub repository to help protect important branches from broken builds. The Aviator bot uses GitHub Labels to identify Pull Requests (PRs) that are ready to be merged, validates CI checks, processes semantic conflicts, and merges the PRs automatically.
ChangeSets – workflows to synchronize validating and merging multiple PRs within the same repository or multiple repositories. Useful when your team often sees groups of related PRs that need to be merged together, or otherwise treated as a single broader unit of change.
TestDeck – a tool to automatically detect, take action on, and process results from flaky tests in your CI infrastructure.
Stacked PRs CLI – a command line tool that helps developers manage cross-PR dependencies. This tool also automates syncing and merging of stacked PRs. Useful when your team wants to promote a culture of smaller, incremental PRs instead of large changes, or when your workflows involve keeping multiple, dependent PRs in sync.

Try it for free.

The post SonarQube vs Fortify first appeared on Aviator Blog.

The post SonarQube vs Fortify appeared first on Aviator Blog.

What is a monorepo and why use one?

Brian Neville-O'Neill — Wed, 29 Nov 2023 18:39:26 +0000

Managing a sprawling codebase across multiple repositories can be a logistical nightmare. Developers often find themselves juggling various versions, wrestling with incompatible dependencies, and navigating a maze of pull requests and merges.

This chaos not only hampers productivity but also increases the risk of errors and inconsistencies. Are you tired of this disarray and looking for a streamlined way to manage your projects?

The answer lies in adopting a monorepo (aka a monolithic repository). One of the most compelling benefits of a monorepo is its ability to simplify version control.

In a traditional multirepo setup, each project or component has its own repository, often leading to versioning conflicts and making it difficult to keep track of changes across projects. With a monorepo, all your code lives in one place, making it easier to manage versions and maintain a coherent history.

This centralized approach ensures that everyone on the team is working with the same codebase, reducing the likelihood of versioning issues and making rollbacks more straightforward.

In this comprehensive guide, you’ll gain insights into what a monorepo is and how it differs from traditional multirepo strategies. You’ll also learn about the advantages of using a monorepo, particularly for larger teams dealing with complex projects.

What is a monorepo?

A monorepo is a software development strategy where the code for multiple projects is stored in a single version control system (VCS) repository:

This differs from the more traditional approach where each project or module has its own separate repository (aka a multirepo):

The projects within a monorepo can be interconnected libraries, services, applications, or even documentation.

The central idea of a monorepos is to consolidate the codebase, ensuring more streamlined version control, code reuse, and improved collaboration. For larger teams, this means better code visibility, simplified dependency management, and the possibility of atomic changes across multiple projects.

Why you should use monorepos

One of the main advantages of using a monorepo is unified versioning. In a traditional multirepo setup, each project has its own version history, making it challenging to understand how changes in one project affect others. With a monorepo, all projects share a single version history, making it easier to understand their interdependencies.

For example, if Project A depends on a feature in Project B, both can be updated simultaneously in a single commit, making it easier to track changes and dependencies.

Following are a few more advantages of using a monorepo:

Reusable code across projects

While it’s true that package managers can help sync dependencies across multiple repositories, having all code in a single repository makes it even easier to share and reuse code. There’s no need to publish internal packages just to share common utilities or components.

This is particularly beneficial for large teams where multiple projects often have overlapping requirements. Code reusability in a monorepo ensures that developers can easily leverage existing code, reducing duplication and accelerating development cycles.

Easier refactoring ensures consistency

In a monorepo, refactoring becomes a less daunting task. Changes can be made once and propagated across all dependent projects in a single commit.

This ensures that improvements or fixes are consistently applied, reducing the risk of one project lagging behind in terms of code quality or features.

Enhanced collaboration through visibility

Monorepos offer improved visibility, allowing teams to better communicate and collaborate. In a large team, this is especially beneficial. Developers can see the entire codebase, understand the context of their work better, and make cross-project changes effortlessly.

This holistic view eliminates the need for special permissions to access different repositories, making it easier for team members to assist each other and encourage code reuse.

Streamlined dependency management

Managing dependencies in a large team can be cumbersome with multiple repositories. A monorepo ensures that there’s a single version of each dependency, reducing conflicts and making updates more predictable.

This centralized approach to dependency management eliminates the “it works on my machine” type of problem, as every team member works with the same set of standardized tools and configurations.

Atomic changes for better version control

In large teams, coordinating releases and updates can be a complex task. Monorepos enable atomic changes, allowing related modifications across multiple projects to be committed at once. This ensures that features or fixes affecting multiple projects are released cohesively, making version control more straightforward and reliable.

Optimized CI/CD pipelines

One of the benefits of monorepos is that continuous integration, continuous deployment (CI/CD) are more streamlined. There’s no need to sync multiple repositories or ensure cross-repo compatibility.

The unified nature of a monorepo allows build and test tools to be standardized, ensuring that everyone is testing and deploying based on the same criteria.

This is particularly advantageous for large teams, where maintaining consistency in CI/CD practices is crucial for efficient and reliable software delivery.

By understanding these benefits in the context of large teams, it becomes clear why monorepos are becoming increasingly popular. They offer a unified, streamlined, and efficient approach to software development that is especially advantageous in complex, multiproject environments.

Monorepo challenges and tools that can help

Monorepos have surged in popularity, especially among large tech giants, due to their myriad advantages. But they’re not a one-size-fits-all solution and come with their own set of challenges. Explore some of these challenges and learn about tools that can help.

Scaling issues

As the codebase within a monorepo grows, so does the build time. Every time a change is made, the CI system might try to rebuild and retest the entire codebase, making the process slow and cumbersome.

To help with these scaling issues, build tools like Bazel, Pants, and Buck2 are specifically designed to optimize the build process through a technique known as incremental builds. Incremental builds minimize the strain on system resources, allowing for more efficient use of hardware, whether you’re working on a local machine or in a cloud-based development environment.

Unlike traditional build systems that recompile the entire codebase every time a change is made, these tools are smart enough to identify which parts of the codebase are affected by recent changes.

These tools are built to seamlessly integrate into your existing development workflow. Once configured, they can automatically detect changes in the codebase and trigger the appropriate incremental builds. This automation is particularly beneficial in a CI/CD environment, where rapid and frequent builds are the norm.

While these tools offer powerful capabilities, they do come with an initial learning curve. Each tool has its own set of configurations, syntax, and best practices that you need to familiarize yourself with. However, the investment in learning is often justified by the significant gains in build speed and efficiency.

Another advantage of using these specialized build tools is their flexibility. They allow for a high degree of customization, enabling you to tailor the build process to meet the specific needs of your project or team. This is especially useful in large teams or complex projects where generic build configurations may not be sufficient.

High complexity

For newcomers or even seasoned team members, navigating a huge codebase can be daunting. Understanding the interdependencies, finding the right modules, or even simply knowing where to start can be overwhelming.

Code navigation tools such as Sourcegraph and integrated features within platforms like GitHub serve as invaluable aids for developers navigating extensive codebases. These tools go beyond basic text search to offer a range of advanced functionalities designed to make code exploration more efficient and insightful.

One of the primary features of these tools is advanced code search, which allows developers to perform complex queries to find specific code snippets, functions, or even documentation within a large codebase. This is particularly useful when you’re trying to understand how a particular piece of code interacts with other components or when you’re debugging.

Another powerful feature is cross-referencing, which enables developers to easily find where a particular function or variable is used across different files or projects. This is incredibly helpful for understanding the impact of potential changes or for tracking down the root cause of a bug. It eliminates the need to manually search through multiple files, saving both time and effort.

These tools also offer intelligent code mapping, which provides a visual representation of how different parts of the code are interconnected. This can be especially useful for new team members who are trying to get a grasp of a complex project or for any developer who wants to understand the architecture and dependencies within the codebase.

Potential for conflicts

With many developers working simultaneously on the same repository, the chances of conflicting changes or merge conflicts increase. This can hamper the development speed and lead to errors if not resolved correctly.

VCS like Git offer robust mechanisms to handle merge conflicts. Features like pull requests in platforms like GitHub or Bitbucket allow for code review, helping spot and resolve conflicts before they’re merged into the main branch.

Additionally, automated testing tools like Jenkins, Travis CI, or CircleCI can automatically run tests on branches before they’re merged. This ensures that any breaking changes or conflicts get flagged early.

As you can see, while monorepos have their disadvantages, there’s a range of tools designed to mitigate these challenges.

Building a monorepo culture

The decision to use a monorepo goes beyond just tools and technical considerations; it requires a cultural shift in how developers work and collaborate. This culture is foundational to effectively managing and scaling a monorepo environment, ensuring that the benefits outweigh the challenges.

Take a look at a few different aspects of building a monorepo culture.

Shared responsibility

In a monorepo setting, boundaries between projects or components become blurred. Instead of viewing projects as isolated entities, team members should see the entire repository as their domain. That’s why it’s important to encourage collaboration across teams. Cross-team code reviews, pair programming, and team rotations can break silos and foster a holistic view of the codebase.

Additionally, you should regularly organize internal workshops, tech talks, or code walkthroughs. This can help team members familiarize themselves with different parts of the codebase and understand its intricacies.

For instance, Google fosters an environment in which developers have the freedom to access and contribute to any section of the codebase. This approach to code ownership has led to standardized coding practices, enhanced collaboration among team members, and a simplified process of reusing code.

Early merging to catch integration Issues

Consistently merging code changes is a proactive approach to software development that helps catch integration issues at an early stage. By integrating changes frequently, you can identify conflicts or bugs sooner rather than later, making them easier to resolve.

This practice minimizes the risk of encountering larger, more complicated issues in the future, which could require significant time and effort to fix. For example, if two developers are working on features that affect the same piece of code, early merging will reveal any incompatibilities between their changes, allowing for quicker adjustments.

To manage these merges in a more organized fashion, implementing branching strategies like feature branching or trunk-based development is highly recommended.

In feature branching, each new feature or bug fix is developed in its own branch. This allows developers to work on different features simultaneously without affecting the main codebase. Once the feature is complete and tested, it can be merged back into the main branch.

Feature branching is particularly useful for teams that have multiple developers working on different aspects of a project, as it allows for parallel development without the risk of one feature negatively impacting another.

In comparison, trunk-based development encourages developers to merge their changes directly into the trunk or main codebase as quickly as possible, often multiple times a day. This approach is beneficial for catching integration issues early and ensures that the codebase remains in a consistently deployable state. It’s especially effective for large teams where rapid integration is crucial for maintaining a smooth development workflow.

Take Facebook’s example, where the codebase is designed to empower engineers to “move fast and break things,” signifying a culture that values swift innovation along with ongoing refinement and iteration.

Thorough documentation

A monorepo’s vastness makes it challenging to navigate and understand. Comprehensive documentation acts as a map, guiding developers through the code.

Make sure you establish clear standards for documenting code. This might include things like comments, READMEs, and architecture diagrams.

Additionally, use tools like Doxygen, Javadoc, or Sphinx to automatically generate documentation from source code comments.

Continual refinement for a healthy codebase

As your codebase grows and evolves, it’s essential to periodically revisit and fine-tune existing code. This practice ensures that your code stays clean, efficient, and in line with current best practices. For instance, an algorithm that was efficient a year ago may now have a more optimized version, or a library you’re using might have received updates that you can take advantage of.

To systematically address this, consider dedicating specific sprints or time periods exclusively to code refactoring and reducing technical debt. For example, you could allocate the last week of every development cycle to revisit sections of the code that have been flagged for optimization or refactoring. This focused effort ensures that your codebase doesn’t accumulate quick fixes or workarounds that can make it harder to maintain and scale over time.

In addition, encourage a culture of detailed code reviews that go beyond just assessing functionality. These reviews should also scrutinize the quality of the code, examining factors like readability, efficiency, and adherence to coding standards. Peer feedback during these reviews can be invaluable for identifying areas that may require refactoring. For example, a team member might notice that a particular function is overly complex and suggest breaking it down into smaller, more manageable functions, thereby improving both readability and maintainability.

By continually refining your code, dedicating time to tackle technical debt, and fostering a culture of thorough code reviews, you can maintain a high-quality, efficient codebase that is easier to work with and less prone to issues in the long run.

Monorepo culture at tech giants

Monorepo culture has been adopted by many tech giants and renowned companies due to the myriad advantages it offers. Take a quick look at how Google, Facebook, and Microsoft have adopted a monorepo culture:

Google

Google is often credited for popularizing the monorepo approach through its massive monolithic codebase known as Piper, which contains billions of lines of code and thousands of projects.

At Google, a culture of shared ownership encourages developers to access and contribute to any part of the codebase. This collaborative approach has led to consistent coding standards, enhanced collaboration, and easier code reuse.

In conjunction with this, Google created Bazel, a build tool designed to work with large codebases like theirs. Bazel supports incremental builds, ensuring only affected components are rebuilt, significantly speeding up the build process.

Facebook

Facebook also employs a monorepo for its vast collection of projects, including the main Facebook app, Instagram, and WhatsApp.

Facebook’s codebase encourages engineers to “move fast and break things,” meaning they actively engage in rapid innovation while also continuously refining and iterating.

In conjunction, Facebook uses Buck, a build system tailored for their monorepo. It ensures efficient and reproducible builds, which is vital given the scale and pace of their development.

Microsoft

Microsoft famously transitioned the Windows codebase to a monorepo using Git, the largest Git repo on the planet. With the move, Microsoft aimed to increase developer productivity, improve code sharing, and streamline the engineering system.

To manage the massive repository, Microsoft developed the Virtual File System for Git (VFS for Git). It allows the Git client to operate at a scale previously thought impossible by virtualizing the filesystem beneath the repo and making it appear as though all the files are present when, in reality, they are not.

These companies not only showcase the technical adaptability of monorepos but also emphasize the cultural shift essential for such a model’s success.

The benefit of monorepos

Deciding between monorepos and multirepos isn’t solely a technical decision—it encapsulates a team’s collaboration dynamics, accountability distribution, and holistic view toward software creation. When complemented with the right tools and a strong culture emphasizing shared ownership and ongoing refinement, monorepos can create a vibrant, streamlined, and unified framework for software initiatives, particularly for larger teams.

Beyond technical merits, monorepos foster an enhanced collaborative environment. They dissolve barriers between developers, promoting shared responsibility, comprehensive code reviews, and a unified development environment.

Together, these features make monorepos a compelling choice for teams seeking both technical efficiency and collaborative synergy.

Aviator: Automate your cumbersome processes

There are 4 key components to Aviator:

MergeQueue – an automated queue that manages the merging workflow for your GitHub repository to help protect important branches from broken builds. The Aviator bot uses GitHub Labels to identify Pull Requests (PRs) that are ready to be merged, validates CI checks, processes semantic conflicts, and merges the PRs automatically.
ChangeSets – workflows to synchronize validating and merging multiple PRs within the same repository or multiple repositories. Useful when your team often sees groups of related PRs that need to be merged together, or otherwise treated as a single broader unit of change.
TestDeck – a tool to automatically detect, take action on, and process results from flaky tests in your CI infrastructure.
Stacked PRs CLI – a command line tool that helps developers manage cross-PR dependencies. This tool also automates syncing and merging of stacked PRs. Useful when your team wants to promote a culture of smaller, incremental PRs instead of large changes, or when your workflows involve keeping multiple, dependent PRs in sync.

Try it for free.

The post What is a monorepo and why use one? first appeared on Aviator Blog.

The post What is a monorepo and why use one? appeared first on Aviator Blog.

Building a CI/CD pipeline for a Google App Engine site using CircleCI

Brian Neville-O'Neill — Mon, 27 Nov 2023 18:21:14 +0000

In this article, we will build a CI/CD pipeline for a Google App Engine Site using CircleCI.

Prerequisite

Python installed on your system
Google Cloud CLI installed

What we are building

Documentation site and connect it to GCP (Google Cloud Platform)
Using CircleCI for automation

What is CircleCI?

CircleCI is a popular choice for software engineers, particularly DevOps engineers when working on automation and overall CI/CD integrations. The CI/CD platform helps software teams automate the process of building, testing, and deploying code. As a cloud-based platform, CircleCI allows you to seamlessly integrate with any version control system you choose, such as GitHub, Bitbucket, or GitLab. However, we will be working with GitHub on this article.

One cool thing about CircleCI is that it lets developers define pipelines that automate the process of building, testing, and deploying code. Pipelines are composed of jobs, which are individual steps in the CI/CD process. Jobs can be configured to run on various platforms, including Linux, macOS, and Windows.

Why Circle CI?

CircleCI is a friendly tool for teams of all sizes, ranging from small startups to large enterprises. No wonder the tool is usually “top of the ladder” during CI/CD integrations. It is a powerful tool that can help teams improve the quality and speed of their software development process.

Improved code quality: CircleCI can help enhance code quality by automating the testing process.
Reduced deployment time: CircleCI can help reduce the time it takes to deploy code by automating the process of building and deploying.
Increased confidence in releases: CircleCI can help increase confidence in releases by ensuring that code is thoroughly tested before deployment.
Improved team communication: CircleCI can help to improve team communication by providing a central location for monitoring the progress of builds and tests.

Relevant CircleCI features

Some of the core features of CircleCI include:

Parallelism: Jobs can be run in parallel to improve the speed of the CI/CD process.
Caching: CircleCI can cache build artifacts and test results to improve the speed of subsequent builds.
Notifications: CircleCI can notify team members when builds fail or pass.
Monitoring: CircleCI provides a dashboard that allows teams to monitor the progress of their builds and tests.

Getting started

To get started, we first need to create a free GitHub repo (I assume you already know how to do that). The next step is to clone the empty repo. After this, let’s create a Python virtual environment by running the following command on your terminal:

pipenv shell

This is what it should look like after a successful installation:

Next is to run the command:

pip install sphinx

Sphinx is a popular documentation generator written in Python that is widely used for creating high-quality documentation for Python projects. It is known for its ease of use, comprehensive features, and extensive support for various output formats.

The next step is to get a Sphinx quick start. To do this, head over to the get started section of Sphinx’s official site and run this command:

sphinx-quickstart

Once you run the command, you get asked a series of questions, exactly the ones in the image below:

Respond to these questions until the whole process is complete.

This whole process creates a build and source directory. We are also going to install Sphinx make files by running this command:

make html

After running the command, your project should look like this in your code editor:

Within the build directory, we have our website files, which look this:

📦build
 ┣ 📂doctrees
 ┃ ┣ 📜environment.pickle
 ┃ ┗ 📜index.doctree
 ┗ 📂html
 ┃ ┣ 📂_sources
 ┃ ┃ ┗ 📜index.rst.txt
 ┃ ┣ 📂_static
 ┃ ┃ ┣ 📜alabaster.css
 ┃ ┃ ┣ 📜basic.css
 ┃ ┃ ┣ 📜custom.css
 ┃ ┃ ┣ 📜doctools.js
 ┃ ┃ ┣ 📜documentation_options.js
 ┃ ┃ ┣ 📜file.png
 ┃ ┃ ┣ 📜language_data.js
 ┃ ┃ ┣ 📜minus.png
 ┃ ┃ ┣ 📜plus.png
 ┃ ┃ ┣ 📜pygments.css
 ┃ ┃ ┣ 📜searchtools.js
 ┃ ┃ ┗ 📜sphinx_highlight.js
 ┃ ┣ 📜.buildinfo
 ┃ ┣ 📜genindex.html
 ┃ ┣ 📜index.html
 ┃ ┣ 📜objects.inv
 ┃ ┣ 📜search.html
 ┃ ┗ 📜searchindex.js

When we run our project on localhost:8000, this is what it looks like on the browser:

Congratulations, we have our documentation site live!

Creating a GCP project

In this section, we will create a brand new GCP project to figure out which settings need to be tweaked or updated from the base. The next thing is to create our app engine app.yaml. Google provides a walkthrough on how to host a static website using GAE. Here, we can copy this YAML file:

runtime: python27
api_version: 1
threadsafe: true

handlers:
- url: /
  static_files: www/index.html
  upload: www/index.html

- url: /(.*)
  static_files: www/1
  upload: www/(.*)

Create an app.yaml file on your editor and paste this code. We then have to edit the YAML file to point it to the proper location where the website files live. To point your Gcloud command line install to this project, use this command:

gcloud init --project=<"project ID">

Here, you will prompted to log in to Google Cloud like this:

Follow the link provided to get your authorization code.

On the GCP dashboard, navigate to “App Engine” and run the command shown there on your terminal:

glcloud app deploy

You will get a prompt asking you to choose the location you would like your app to be deployed:

Choose anyone! and your app will successfully deploy. It’s time to push our code to Github! Alternatively, you can clone my GitHub repo here.

Link Github repo to CircleCI

The first thing you need to do is create a CircleCI account and link your Github to it. The process is pretty straightforward. Our dashboard should look like this after creating and connecting our project to CircleCI.

Next, in our code editor, we will create a folder named .circleci and a config.yaml file inside it which contains a code that works like this: first, it defines a workflow, then, the workflow will say; each time we push to the main branch, run this set of jobs. We will also define that job, which will contain the logic of where we build our documentation site and deploy it to the Google App engine.

workflows:
  version: 2
  build_and_deploy:
    jobs:
      - build_and_deploy:
        filters:
          branches:
            only:
              - main

CircleCI will only run this workflow when we push to the main branch. Now, to define the job:

jobs:
  build_and_deploy:
    docker:
      - image: busybox
    steps:
      - run:
          name: hello world
          command: |
            echo "Hello world"

You can check our formatting with CircleCI. To do this, first install CircleCI CLI and run this command:

circleci config validate

Response:

In our CircleCI, you can see the tests, processes, and workflows whenever we push to the main branch on GitHub:

Awesome! We have successfully created a CI/CD pipeline. Now, whenever we make changes to our code base or documentation, we can just push to the main, and CircleCI will pick up that change (as demonstrated in the image above) and the job or workflow and make deployments a few minutes later.

Conclusion

This article provided a step-by-step guide on building a CI/CD pipeline for a Google App Engine site using CircleCI. We covered setting up a Python environment, using Sphinx for documentation, and integrating the project with Google Cloud Platform.

The process demonstrated the benefits of automating deployments via CircleCI, including enhanced code quality, reduced deployment time, and improved team communication. This guide highlights the efficiency and effectiveness of CircleCI in streamlining development processes, making it an invaluable tool for modern software development teams.

Aviator: Automate your cumbersome processes

There are 4 key components to Aviator:

MergeQueue – an automated queue that manages the merging workflow for your GitHub repository to help protect important branches from broken builds. The Aviator bot uses GitHub Labels to identify Pull Requests (PRs) that are ready to be merged, validates CI checks, processes semantic conflicts, and merges the PRs automatically.
ChangeSets – workflows to synchronize validating and merging multiple PRs within the same repository or multiple repositories. Useful when your team often sees groups of related PRs that need to be merged together, or otherwise treated as a single broader unit of change.
TestDeck – a tool to automatically detect, take action on, and process results from flaky tests in your CI infrastructure.
Stacked PRs CLI – a command line tool that helps developers manage cross-PR dependencies. This tool also automates syncing and merging of stacked PRs. Useful when your team wants to promote a culture of smaller, incremental PRs instead of large changes, or when your workflows involve keeping multiple, dependent PRs in sync.

Try it for free.

The post Building a CI/CD pipeline for a Google App Engine site using CircleCI first appeared on Aviator Blog.

The post Building a CI/CD pipeline for a Google App Engine site using CircleCI appeared first on Aviator Blog.

Mckinsey developer productivity metrics: Opportunity isn’t the goal

Brian Neville-O'Neill — Fri, 17 Nov 2023 18:38:17 +0000

Understanding software team performance is essential so business leaders and engineering managers can accurately assess potential optimizations that could improve throughput. However, precise performance measuring remains a challenge for many organizations.

It’s often unclear which metrics should be used, how to analyze them, and whether improving them will actually increase your team’s output.

A recent McKinsey report argues that software teams should focus their benchmarks on opportunities. An opportunity represents the possibility of effecting an improvement in product quality or the efficiency of the development process.

In this article, we’ll analyze this method and how it complements established frameworks like DORA and SPACE.

What is opportunity-driven performance measurement?

Software development is a multi-faceted, collaborative, and iterative discipline that requires continual effort from everyone on the team. Modern software companies rarely have idle time; as soon as one feature sprint begins, the focus immediately moves to the next one.

Therefore, it’s important that the development cycle facilitates gradual improvements over time, to ensure the team can keep making productivity enhancements without being overwhelmed by the burden of existing work.

These pathways to improvement are the “opportunities” described by McKinsey’s methodology. The approach is designed to let organizations analyze whether their teams are able to move forward, without demanding the use of heavy instrumentation.

Assessing whether teams have the opportunity to improve provides several benefits:

You can determine whether a team is at risk of being overworked: Teams with few opportunities to improve will be too busy to take on additional work or prioritize internal optimizations.
Understand how teams feel about their work: Fewer opportunities can indicate that teams are stifled in their creative abilities. If all engineering efforts have to go in one direction, then there’s a higher risk of burnout.
Identify a team’s proficiency, relative to its peers: Teams that are creating more opportunities can be more technically proficient than their peers. They solve solutions in a shorter time, leaving more room to implement improvements in the delivery process.
Assess whether you have enough overall capacity to innovate: If all your teams are struggling to create opportunities to improve, then it means you’re at the limit of what you can achieve with your current capacity. You might be able to fulfill existing obligations but will be unable to meet any additional pressures (such as rapidly launching new features to respond to competitor announcements).
Gain assurance that teams are delivering value to the business: Teams that have a very high opportunity score—relative to other teams in your organization—might actually be delivering relatively little business value. It could mean they have too much idle time or are preoccupied with process enhancements, to the detriment of value-creating work.

It’s clear from this list that “opportunities created” is a valid metric for tracking software development performance. But how do you actually measure available opportunities?

Opportunity-driven metrics explained

McKinsey suggests four primary “lenses” to look through:

Time spent in the inner/outer loop
Developer Velocity Index benchmark
Analysis of backlog contributions
Talent capability score

Let’s explore how these metrics provide improvement opportunities for your organization.

1. Time spent in the inner/outer loop

The software development lifecycle incorporates inner and outer loops. The inner loop is where work gets done; it mainly consists of writing, testing, building, and deploying code. The outer loop encapsulates administrative tasks that can distract and frustrate developers; examples include planning meetings, compliance audits, and collaboration with other teams.

Capturing the time spent in each loop provides information that offers a picture of opportunities. Ideally, developers should be spending the majority of their time in the inner loop, as this is where they’re contributing the most value to the organization.

Teams or individuals that are getting stuck in the outer loop will be spending more time on less productive tasks, limiting your opportunities to progress other work.

2. Developer velocity index benchmark

McKinsey’s existing Developer Velocity Index (DVI) benchmark encapsulates performance across several verticals including tooling, working methods, process optimization, and compliance. Teams or individuals with high DVI scores are equipped to capitalize on more opportunities; they are consistently productive at high rates of throughput, which creates windows between regularly scheduled work in which improvements can be made.

Tools are available to help you calculate DVI. You can also produce your own version by combining performance and activity metrics such as the number of commits made, issues closed, discussions contributed, and features delivered by each individual or team.

Developer satisfaction should be considered too, as frustration or inability to operate autonomously will usually impede velocity.

3. Analysis of backlog contributions

The tasks that a team or individual works on can reveal opportunities to either reassign work or encourage upskilling. Firstly, developers who routinely work on backlog tasks represent an increased opportunity as they’re delivering additional value beyond what may be expected.

If those backlog tasks fall slightly outside the developer’s usual expertise, then successfully tackling them implies there’s a retraining opportunity as the engineer has already demonstrated proficiency with those skills.

The opportunity might not necessarily relate to the specific developer who’s working on the tasks. For example, if developers are routinely undertaking infrastructure tasks—but they’re taking a relatively long time to reach completion—then the opportunity is to introduce more operations staff who are better equipped to deal with those tickets. This then frees up the software team to deliver a higher throughput on their specialist development work.

4. Talent capability score

A talent capability score summarizes the skills and abilities held within a team or organization. It also encapsulates the distribution of skill levels, from beginner through to senior experts.

High-performing organizations will need a breadth of skills across DevSecOps sectors, with a range of skill levels for each one—junior developers are required to ensure fresh talent enters the business, but these must be supported by senior staff. Having too many people with similar proficiency can impede you in the long term, reducing your talent capability score.

Advanced talent capability means more opportunities to deliver throughput and process improvements. Different perspectives will make it more likely that new working methods will be discovered. Similarly, having a good spread of proficiencies allows you to sustain performance long-term by coaching and mentoring newcomers into senior roles.

This progression pathway can make the organization more attractive to developers, increasing staff retention rates and hence producing an additional increase in opportunity.

The challenges of using opportunity metrics for performance measurement

McKinsey’s report has prompted more debate about whether, how, and why software performance should be measured. Looking at the opportunity as a benchmark for performance is a novel idea that encourages a more holistic framing of results while recognizing the iterative, long-term nature of modern software lifecycles.

However, actually collecting and utilizing this data is likely to be challenging for many organizations. Moreover, the metrics don’t necessarily tell the whole story—similarly to DORA and SPACE, you need to analyze them in the context of your organization’s working methods and business aims.

Having a theoretical opportunity to improve isn’t necessarily meaningful, such as if it relates to a low-priority project or you’re already satisfying all performance objectives.

Opportunity isn’t the goal

Perhaps the biggest drawback of focusing on opportunity is that creating opportunities shouldn’t actually be your goal. Ultimately, software teams are always going to be guided by outputs. An opportunity represents a possibility of an outcome, but it doesn’t guarantee you will realize it. To tangibly improve, you must utilize your opportunities to drive improvements across your development lifecycle.

The metrics discussed here won’t directly tell you whether that’s happening. For example, you could hire more proficient developers to optimize your talent capability score. This creates an opportunity to achieve higher throughput—but are you actually capitalizing on that opportunity?

This question must be answered to understand whether continuing the investment is an effective way to further increase throughput. (The answer will also be the primary concern of business and finance teams who want to know whether the new hiring wave has generated financial ROI.)

It can be tempting to assume that the new highly skilled developers will immediately start producing results, but the reality could be very different. If you don’t have the tools and processes to support effective collaboration, then your engineers might actually be sitting idle.

Consequently, it’s imperative that apparent opportunities are approached with caution. You must conduct your own research to determine whether opportunities are being actioned, which could involve consideration of trends shown in outcome-oriented performance data—such as DORA’s average deployment frequency and change failure rate values.

Even so, it may still be difficult to accurately attribute those changes back to your opportunity results. Hence, analyzing opportunities could raise more questions than it solves if you can’t measure whether available opportunities are being converted into actual improvements.

Opportunity means obfuscation

Because opportunity must be seen only as an enabler of outcomes—not a target outcome in itself—it means that this method adds another degree of obfuscation to your performance analysis. It is a helpful way to interpret how performance could change in the future, but it certainly does not mean that it will change in a particular way.

Zeroing in on opportunity while disregarding other benchmarks could therefore distract from more meaningful optimizations. Obfuscating simpler development metrics (such as a team being understaffed, or deployments taking too long to complete) behind obscure “opportunity” scores won’t be helpful to teams already struggling to get a grip on performance.

Opportunity is therefore best-used as an indicator that you’re on the right track. It shouldn’t be used in isolation, but for high-performing teams, it can help you understand whether you’re on course to sustain and improve your current performance. It recognizes the reality that continual reinvestment of time and resources is required to keep improving processes, and hence increase productivity.

In summary, measures such as DORA, SPACE, and your own business metrics can help you understand what’s working and what needs improvement in your software development processes. Opportunity analysis offers an additional dimension that suggests whether you’re equipped to implement those improvements across your processes and products. However, this is a derived value that can obscure important details, so it must always be tied back to your organization’s context.

Conclusion

Software development performance is topical but getting a handle on it is still hard. DORA and SPACE provide measurements for how you’re performing today, but they don’t always reveal whether you’re on a trajectory for future growth.

Assessing the opportunities being created by your teams helps build a more complete picture of long-term performance. Without the opportunity to improve, you can’t pursue the process optimizations, efficiency enhancements, and toolchain revisions that are critical to scaling DevOps teams to match product growth and market demands.

That said, the model still won’t give you a definitive picture of overall productivity. There can be multiple reasons why a metric changes or a trend appears, so it’s vital you interrogate your data to ensure that findings are real and relevant. For this reason, it’s usually best to start off small by collecting a few performance metrics—across DORA, SPACE, and opportunity analysis—that are easily measurable and have a clear impact on your business.

Aviator: Automate your cumbersome processes

There are 4 key components to Aviator:

MergeQueue – an automated queue that manages the merging workflow for your GitHub repository to help protect important branches from broken builds. The Aviator bot uses GitHub Labels to identify Pull Requests (PRs) that are ready to be merged, validates CI checks, processes semantic conflicts, and merges the PRs automatically.
ChangeSets – workflows to synchronize validating and merging multiple PRs within the same repository or multiple repositories. Useful when your team often sees groups of related PRs that need to be merged together, or otherwise treated as a single broader unit of change.
TestDeck – a tool to automatically detect, take action on, and process results from flaky tests in your CI infrastructure.
Stacked PRs CLI – a command line tool that helps developers manage cross-PR dependencies. This tool also automates syncing and merging of stacked PRs. Useful when your team wants to promote a culture of smaller, incremental PRs instead of large changes, or when your workflows involve keeping multiple, dependent PRs in sync.

Try it for free.

The post Mckinsey developer productivity metrics: Opportunity isn’t the goal first appeared on Aviator Blog.

The post Mckinsey developer productivity metrics: Opportunity isn’t the goal appeared first on Aviator Blog.

Automating integration tests: Tools and frameworks for efficient QA

Brian Neville-O'Neill — Thu, 09 Nov 2023 20:06:28 +0000

In today’s fast-paced software development environment, the need for rapid and reliable testing is paramount. One essential aspect of testing is integration testing, which ensures that different components of a software system work seamlessly together.

In this article, we will explore the benefits of automating Integration testing in software development, and a case study using three popular tools to illustrate the implementation of automated integration testing in a real-world scenario.

What is integration testing?

Integration testing is a level of software testing in which individual units or components of a software application are combined and tested as a group. The primary goal of integration testing is to ensure that the interactions between these components when integrated, work as expected and that the application functions correctly as a whole.

Unit Testing vs. Integration Testing:

Scope:

Unit Testing: Tests individual units in isolation (functions, classes).
Integration Testing: Tests interactions and interfaces between integrated units.

Testing Depth:

Unit Testing: Focuses on internal logic of a single unit, avoids external dependencies.
Integration Testing: Validates interactions between multiple units, includes external dependencies like databases or APIs.

Purpose:

Unit Testing: Verifies correctness of individual units, catches bugs within a unit.
Integration Testing: Ensures collaboration between units, detects integration-related issues.

Dependencies:

Unit Testing: Independent of external dependencies, uses test doubles (mocks, stubs).
Integration Testing: Requires external dependencies, verifies integration points with other components.

Unit testing is concerned with the correctness of individual units of code, while integration testing focuses on the interactions and integration of multiple units to ensure they work together as expected.

Importance of integration testing in software development

Integration testing is a critical phase in the software development lifecycle where individual components or modules of a system are tested together to uncover issues related to their interactions.

This type of testing ensures that various parts of a software application collaborate as intended and that data flows correctly between them.

Benefits of integration testing

Interface Issues: Identifies data passing errors, inconsistent APIs, and communication breakdowns.
Error Localization: Pinpoints failure locations for quicker fixes.
End-to-End Functionality: Verifies software’s correct operation for a reliable user experience.
Risk Reduction: Early issue detection lowers the risk of critical problems in later stages.

Challenges in manual integration testing?

Manual integration testing, while necessary, can be a time-consuming and error-prone process. Here are some of the challenges associated with manual integration testing:

Manual testing for complex software is time-consuming, slowing down development cycles.
Requires dedicated testers, incurring high costs for organizations.
Human error can introduce inconsistencies in test execution and miss critical scenarios.
As software complexity increases, manual testing struggles to scale with the growing number of integration points.

Roles of automation in enhancing integration testing

Automation is the solution to many of the challenges posed by manual integration testing. By leveraging automation tools and frameworks, you can streamline the testing process, improve accuracy, and expedite the feedback loop. Here’s how automation enhances integration testing:

Speed: Automated tests run faster, enabling frequent testing cycles.
Consistency: Tests execute consistently, reducing human errors.
Coverage: Automation tests a wide range of scenarios comprehensively.
CI/CD Integration: Seamless integration provides immediate feedback on code changes, allowing early issue detection.

In the subsequent sections of this article, we will delve deeper into the tools and frameworks available for automating integration testing.

How to choose the right tools and frameworks for automation testing

Selecting the right tools and frameworks for automating integration tests is a crucial decision that can significantly impact the efficiency and effectiveness of your testing efforts. Let’s explore the criteria for tool selection and discuss some popular automation tools and testing frameworks for integration tests.

Criteria for tool selection

When evaluating testing tools for your integration testing needs, consider the following criteria to make an informed decision:

Programming Languages and Technologies Compatibility
Community Support and Documentation
Reporting and Visualization Capabilities

Popular automation tools

Let’s take a closer look at some popular automation tools commonly used for automating integration tests:

Selenium – Downloads | Selenium

Language Support: Selenium supports multiple programming languages, including Java, Python, C#, and JavaScript, making it versatile for various development environments.
Browser Compatibility: Selenium is widely used for web application testing and supports a broad range of web browsers, including Chrome, Firefox, Safari, and more.
Community: Selenium has a large and active community, which means extensive online resources, forums, and support.

Cypress – JavaScript Component Testing and E2E Testing Framework | Cypress

Focused on Web Applications: Cypress is designed specifically for testing web applications and provides a rich set of features tailored to this domain.
JavaScript: Cypress uses JavaScript for test scripting, which may be advantageous if your project primarily involves JavaScript development.
Interactive Debugging: Cypress offers real-time debugging capabilities, allowing testers to see what happens at each step of a test.

Postman – Download Postman | Get Started for Free

API Testing: Postman is a popular tool for testing APIs. It allows you to create and execute API requests, making it ideal for integration testing of APIs.
Collections: Postman collections enable the organization of API requests into logical groups, facilitating test case management.
Automation: Postman provides options for automating API tests, making it suitable for incorporating into CI/CD pipelines.

Testing frameworks for integration tests

In addition to automation tools, you would also need testing frameworks to structure and manage your integration tests. Here are some commonly used testing frameworks for integration testing:

Pytest (Python) – pytest Documentation :

Python Support: Pytest is a popular testing framework for Python applications, offering a simple syntax and powerful test discovery mechanisms.
Rich Ecosystem: Pytest has a rich ecosystem of plugins and extensions that enhance its functionality and support various testing needs.

TestNG (Java) – TestNG – Documentation :

Java Support: TestNG is a testing framework for Java applications. It provides advanced features such as parallel test execution, data-driven testing, and test grouping.
Annotations: TestNG uses annotations to define test methods and specify test configurations, making it easy to create and manage test suites.

NUnit (C#) – NUnit.org :

C# Support: NUnit is a testing framework for C# applications, offering similar features to JUnit and TestNG.
Attributes: NUnit uses attributes to define tests and test fixtures, making creating and managing test suites in C# projects easy.

These tools and frameworks, when used in conjunction with best practices, can streamline your testing efforts, improve test coverage, and contribute to the overall quality of your software.

Setting up automation for integration tests

Let’s talk about some of the essential steps required to set up automation for integration tests include configuring the testing environment, managing dependencies, and writing test scripts.

Environment configuration and dependencies

Environment Setup:

Development Environment: Set up necessary software and libraries for test automation, including code editors, version control systems, and language runtimes.
Testing Environment: Create a testing environment mirroring the production setup for accurate testing.

Dependency Management:

Package Managers: Utilize npm, pip, or Maven to manage project dependencies and automation tools.
Virtual Environments: Use tools like Docker to isolate dependencies, ensuring consistency across various development setups.

Writing test scripts

API Testing Tools: Choose tools like Postman or Requests for API interactions, covering diverse endpoints and response scenarios.
Authentication: Implement required authentication methods such as API tokens or OAuth in your tests.
Data Handling: Prepare test data, considering dynamic data generation or using mock data.

Simulating user interactions

UI Automation Tools: Select Selenium or Cypress for simulating user actions in web applications.
Test Cases: Write test cases replicating critical user interactions like form submissions and button clicks.
Asynchronous Actions: Handle asynchronous actions like AJAX requests for accurate testing.
Cross-Browser Testing: Verify application functionality across multiple browsers and versions.
Data Management: Plan test data management, including database setup or generation scripts.
Data Mocking: Use mocking libraries to simulate external services, isolating tests from external factors.
Data Cleanup: Implement mechanisms to clean up test data post-execution for a consistent testing environment.

By following these steps, you can establish a solid foundation for automating integration tests.

How to execute and analyze automated integration tests

Let’s also consider the steps involved in executing and analyzing automated integration tests include running tests locally, integrating them into CI/CD pipelines, generating reports and logs, and interpreting test results and failures.

Running tests locally and in CI/CD Pipelines

Local and CI/CD Test Execution:

Setup: Configure local environment with necessary dependencies and tools.
Running Tests: Execute tests using chosen automation tool via CLI or IDE.
Debugging: Use automation tool features for script debugging.

CI/CD Pipeline Integration:

Version Control: Link repository with CI/CD system for automated test triggers.
Automated Testing: Integrate tests into CI/CD pipeline for continuous validation.
Parallel Execution: Run tests in parallel to optimize pipeline speed.

Generating Reports and Logs:

Test Execution Reports: Automation tools provide detailed test execution reports.
Custom Reports: Develop custom reports for additional insights or visualizations.
Logging: Implement logging in scripts for vital execution data.
Debugging Output: Ensure clear error messages and stack traces for effective debugging.

Interpreting Test Results:

Passed Tests: Validate expected behavior in various scenarios.
Failed Tests: Investigate reasons behind failures, such as incorrect assertions or unexpected responses.
Failure Investigation: Refer to logs, reproduce failures locally, and pinpoint issues.

Root Cause Analysis:

Code Review: Check recent code changes linked to failed tests.
Environment and Data: Consider external factors like environment changes or data inconsistencies.

Bug Reporting and Tracking:

Issue Tracking: Report genuine bugs in project’s issue tracking system.
Re-Run Tests: After fixes, re-run tests to confirm problem resolution.

By following these steps, you can effectively execute and analyze automated integration tests as part of your software development process. This approach ensures you catch integration issues early, facilitate debugging, and maintain a reliable and robust codebase.

Case study: Implementing automated integration testing

This is a case study that illustrates the implementation of automated integration testing in a real-world scenario. We’ll cover the scenario description, tool and framework selection, test script creation and execution, and the results **providing practical examples and guidance on implementing these strategies using popular tools and frameworks, including FastAPI, to help you overcome challenges and automate integration tests successfully.

Scenario description

Scenario:

Imagine you work for a software development company that is building a modern e-commerce platform. The platform consists of various components, including a web application, a RESTful API, and a backend database. Your team is responsible for ensuring the smooth integration of these components and maintaining a high level of quality in the application.

Challenges:

Frequent code changes and feature additions are causing integration issues.
Manual testing is time-consuming, error-prone, and slowing down the development process.
Ensuring that customer data remains secure and consistent across the platform is a top priority.

Tool and framework selection:

Selenium: For UI automation.
Postman: For API testing and executing API requests.
Pytest: For structuring and managing integration tests.

Test script creation and execution

Test Script Creation:

Selenium for UI Test:

When using Selenium to write test, it doesn’t provide a testing tool/framework. You can write test cases using Python’s pytest module. Other options for a tool/framework are unittest and nose. In this example, we use pytest as the framework of choice and chrome’s web driver, Chronium to test the login process in an application. The choice of what web driver to download is as a result what web browser you want to use.

Setup :

Install Selenium, Pytest and download the appropriate WebDriver in this case ChromeDriver, and add to Path. You can check out how to install the ChromeDriver and add it to path here.


# Install the Selenium WebDriver, pytest and necessary browser driver which is ChromeDriver
# pip install selenium pytest
# Download ChromeDriver: https://sites.google.com/chromium.org/driver/downloads

Import Modules :

Import the required module.

from selenium import webdriver
from selenium.webdriver.chrome.options import Options
from selenium.webdriver.common.keys import Keys
from selenium.webdriver.common.by import By

WebDriver Initialization :

Create an instance of the Chrome WebDriver to control the browser.


options = Options()

# To open the browser maximized
options.add_argument("start-maximized")

# To keep the browser open
options.add_experimental_option("detach", True)

# Initialize the web driver (assuming you've downloaded and placed ChromeDriver in your PATH)
driver = webdriver.Chrome(options=options)

Test Function :

Define a test function **test_logIn** for simulating user interactions on the website.
Navigates to the website, inserts the email and password you provided after searching for the field using driver.find_element.
Use the Return key to press enter.

def test_logIn():
    # Insert the 'email' and 'password' credentials
    email = "[email-address]"
    password = "[password]"
   # Navigate to the login page
    driver.get("[website-url]") # Replace with the login page URL

    # Check the title of the page
    assert "TestWebsit" in driver.title 

    # Find and interact with the email and password fields
    email_field = driver.find_element(By.NAME, "email")
    password_field = driver.find_element(By.NAME, "password")

    email_field.send_keys(eamil)
    password_field.send_keys(password)
    # Enter the 'RETURN' key
    password_field.send_keys(Keys.RETURN)

Cleanup :

Close the browser to release resources.

# Clean up: close the browser
driver.quit()

Running Selenium UI Tests:

To run Selenium UI tests, you’ll need to make sure you have the Selenium WebDriver set up and installed. Here’s how to run the Selenium UI tests:

Place your Selenium UI test code in a Python file, e.g., ui_test.py.
Open a terminal and navigate to the directory where ui_test.py is located.
Run the UI test script using Python:

pytest ui_test.py

The script will launch a Chrome browser, navigate to the specified website, perform the user interactions, and verify the results.

Pytest for integration testing

Pytest test cases are written to test the interaction between the web application and the RESTful API. These tests ensure that data flows correctly between the frontend and backend. In this example, the Sign-up endpoint is tested.

Setup

Import the libraries and classes that would be used.

Import Libraries:

Import the libraries and classes that will be used.

import httpx
import pytest
import pytest_asyncio
from typing import AsyncIterator
from fastapi import FastAPI, status
from pydantic_settings import BaseSettings

Create an Endpoint:

Instantiate the FastAPI class
Write a schema for the endpoint you want to create
Create your Endpoint


app = FastAPI()

class Register(BaseSettings):
    username: str
    password: str
    email: str

@app.post("/register", status_code=status.HTTP_201_CREATED)
async def signUp(register: Register):
    return {
        "username": register.username,
        "email": register.email
    }

Fixture for Base URL:

Define a Pytest fixture client that uses the httpx.AsyncClient to make asynchronous operations instead of the FastApi’s TestClient for making synchronous operations

@pytest_asyncio.fixture
async def client() -> AsyncIterator[httpx.AsyncClient]:
    async with httpx.AsyncClient(app=app, base_url="http://testserver") as client:
        yield client

Test Function :

Define an asynchronous test function (**test_api_integration**) for integration testing.
Use an async HTTP client (**httpx.AsyncClient**) to simulate user registration and login.
Assert the response status codes and verify that the data provided is accurate.


@pytest.mark.asyncio
async def test_api_integration(client: httpx.AsyncClient):
    # Simulate a user registration and login process
    registration_data = {
                "username": "testuser",
                "password": "password123",
                "email": "testuser@example.com"
            }

    response = await client.post("/register", json=registration_data)
    assert response.status_code == 201
    assert response.json() == {
                "username": registration_data['username'],
                "email": registration_data['email']
            }
            # Perform additional integration tests as needed

Running Pytest Integration Tests:

To run Pytest integration tests, you’ll need to have your FastAPI application running. Here’s how to run the Pytest integration tests:
1. Place your Pytest integration test code in a Python file, e.g., integration_test.py.
2. Open a terminal and navigate to the directory where integration_test.py is located.
3. Run the Pytest test suite:

pytest integration_test.py

Pytest will discover and run the test functions within the specified Python file. Ensure that your FastAPI server is running and accessible at the base URL specified in the test script.

By following these steps, you can execute the UI, API, and integration tests to verify the functionality of your application. Make sure to customize the test scripts according to your specific application and requirements before running them.
Tests are also integrated into the CI/CD pipeline, triggering automated test runs on each code commit and deployment.

Postman for API Tests

API test suites are developed to verify the functionality of the RESTful API. Tests include endpoints for user registration, product retrieval, and order processing. In this example, we would test the Sign-Up endpoint created while using pytest.

Download the Postman application into your computer and create an account. Alternatively, you can use the Postman web application but in this example, we are making use of the desktop app.

To begin, create a Workspace by clicking the dropdown arrow.
Create a collection by clicking the Create Collection icon.

Provide the URL to the endpoint you want to test, do not forget input the correct http method.

Add a request body if required. In this case, a body is required.
Click Send.

Check the response body to make sure what you want is being returned.

When the Endpoints become much, you can choose to run the collection as a whole instead of testing the endpoints individually.

Results and impact on QA process

Integration issues are detected and resolved much earlier in the development process, reducing the cost and complexity of fixing them.
UI tests with Selenium have identified and resolved several user interface issues, leading to an improved user experience.
API tests in Postman have helped ensure that the RESTful API functions correctly, maintaining data integrity and security.
Integration tests with Pytest have confirmed that the components of the e-commerce platform work seamlessly together, reducing integration-related bugs.

In this case study, the implementation of automated integration testing using Selenium, Postman, and Pytest has significantly improved the software development process. Integration issues are caught early, leading to a more efficient and reliable QA process and a higher-quality e-commerce (example) platform for customers.

Best practices for effective automation

To ensure the success of your automated integration testing efforts, it’s essential to follow best practices that promote efficiency, reliability, and maintainability. Below are some:

Isolate tests to prevent dependencies on prior states.
Programmatic data creation ensures replicable testing.
Implement cleanup mechanisms for a consistent environment.
Regularly update tests to match application changes.
Remove redundant tests for efficiency.
Keep documentation and reports clear, concise, and up-to-date.

In this comprehensive exploration of automated integration testing, we’ve covered the significance of this testing approach and the tools, frameworks, and best practices that enable its successful implementation.

Aviator: Automate your cumbersome processes

There are 4 key components to Aviator:

MergeQueue – an automated queue that manages the merging workflow for your GitHub repository to help protect important branches from broken builds. The Aviator bot uses GitHub Labels to identify Pull Requests (PRs) that are ready to be merged, validates CI checks, processes semantic conflicts, and merges the PRs automatically.
ChangeSets – workflows to synchronize validating and merging multiple PRs within the same repository or multiple repositories. Useful when your team often sees groups of related PRs that need to be merged together, or otherwise treated as a single broader unit of change.
TestDeck – a tool to automatically detect, take action on, and process results from flaky tests in your CI infrastructure.
Stacked PRs CLI – a command line tool that helps developers manage cross-PR dependencies. This tool also automates syncing and merging of stacked PRs. Useful when your team wants to promote a culture of smaller, incremental PRs instead of large changes, or when your workflows involve keeping multiple, dependent PRs in sync.

Try it for free.

The post Automating integration tests: Tools and frameworks for efficient QA first appeared on Aviator Blog.

The post Automating integration tests: Tools and frameworks for efficient QA appeared first on Aviator Blog.

Introducing Aviator’s engineering efficiency calculator

Brian Neville-O'Neill — Tue, 07 Nov 2023 18:58:45 +0000

https://app.aviator.co/calculator

Measuring engineering productivity is a complicated process — it’s hard to get a full picture of how developers spend their time. A common way to measure productivity is to analyze system metrics like DORA or SPACE. These can be extremely useful metrics to understand the productivity of the team compared to the industry standards. Diving into each of those metrics can also provide insights into what’s slowing down the team.

But sometimes there are also “hidden pockets” of time that developers spend throughout their day that may not be perceived as impacting productivity. However, when we start adding those things up the numbers can be alarming.

For instance, consider the amount of time a developer spends debugging a flaky test trying to figure out if it failed because of their change or not. Or, the time spent by a developer who is trying to resolve a mainline build failure.

To provide that perspective, we built a calculator that makes a run at assessing engineering efficiency. By no means does this provide a full analysis of your engineering team’s efficiency. What it does provide is a glimpse of the “hidden pockets” of time wasted that typically do not show up in more common productivity metrics. The calculator focuses on how much time you and your team lose due to build and test failures in developer workflows.

If you compare this to DORA metrics, the lead time for changes is significantly impacted by build and test instability. That impact can be assessed using this calculator.

How it works

We ask you to input data based on your GitHub activities and how you use GitHub branches. To explain the actual calculations below, let’s assign variables to each of them:

M – PRs merged per day

X – mainline failures in a week

T – average CI time

F – flakiness factor %

Based on these inputs, we estimate how much time your engineering team wastes weekly on managing build failures and dealing with flaky tests. Let’s go over the results one by one.

Hours wasted to fix

This calculates how many hours are wasted to identify, triage, fix, and have the build pass again when a mainline build failure is detected. Typically in a large team, someone will notice and report the broken mainline build.

We assume that a mainline build failure involves an average of 1-3 developers to debug and fix. If we consider an average of one hour for the time it takes for the issue to be reported and a fix to be pushed, we are spending (2*T + 1) hours to track, investigate, and resolve the issue.

That means, if there are X failures a week, we are spending ((2 devs * X/5 * (2*T + 1)) hours in developer time to fight mainline build failures every day.

Hours wasted in resolving merge conflicts

Rollbacks and merge conflicts can cause further issues. Assuming that there are roughly 2% PRs that have merge conflicts during the window of broken build time ((2*T + 1) * X/5), and M/8 PRs coming in every hour, we will spend ((2*T + 1) * X/5) * 0.02 * M/8 wasted in resolving these conflicts.

Weekly CI failures due to broken builds

If the team is not using a golden branch to base their feature branches on, they would likely create feature branches on top of a failed mainline branch. Since the number of PRs created during any time would be similar to the average number of feature branches based out of mainline, this would cause (2*T + 1 hour) * X/5 * M/8 number of CI failures happening every day.

Time to resolve CI

With approximately fifteen minutes of context switching the handle every build failure, that’s (2*T + 1 hour) * X/5 * M/8 * 0.25 hours of developer time wasted every day with CI failures.

Time spent rerunning flaky tests

Similarly, with the flaky tests, the context switching time required to investigate whether the test was flaky or real, and rerunning the tests itself takes an average of fifteen minutes per run. Depending on the flakiness factor, the developers would waste (0.25 * M * F / 100) hours every day.

Improving efficiency

Although most of these impact the DORA metrics associated with Lead time for changes, we are still just scratching the surface in terms of measuring the inefficiencies in engineering team workflows. The impact of build and test failures also leads to delayed releases impacting the other DORA metrics like deployment frequency, time to restore service, and persistence of flaky tests in the system can lead to a higher change Failure rate. Learn more about DORA metrics. Or, learn more about their disadvantages.

We built Aviator to solve some of these hidden challenges for large engineering teams. Today, using Aviator MergeQueue many engineering organizations can scale your merge workflow without breaking builds. Combining that with a flaky test suppression system like TestDeck, teams can save hundreds of engineering hours every week.

The post Introducing Aviator’s engineering efficiency calculator first appeared on Aviator Blog.

The post Introducing Aviator’s engineering efficiency calculator appeared first on Aviator Blog.

A modern guide to CODEOWNERS

Brian Neville-O'Neill — Tue, 31 Oct 2023 15:24:47 +0000

In software development, numerous people touch the same code, and it’s crucial to keep track of who is responsible for what. This is where CODEOWNERS come into play.

The CODEOWNERS feature allows you to specify individuals or teams who are responsible for code in a repository, making it easier to manage your projects. This feature can streamline the review process, enhance security, and make sure the right people are responsible for the right code.

In this guide, you’ll learn all about why you need CODEOWNERS and how to effectively use this feature in your software development workflow.

Why you need CODEOWNERS

In order to outline who is responsible for different sections of a codebase, you need to create a CODEOWNERS file in your repository. When a pull request (PR) is opened that touches files listed in the CODEOWNERS file, the designated code owner is automatically asked to review that section of the code. Several popular code hosting platforms support this feature, including GitHub, GitLab, and Bitbucket.

Following are some of the reasons why you should consider implementing CODEOWNERS into your software project:

Enhanced security measures: Defining CODEOWNERS creates a safeguard, ensuring that only designated users or teams can sign off on changes to specific areas of the codebase. This reduces the likelihood of unauthorized or accidental alterations to the code.
Streamlined review mechanism: When you use CODEOWNERS, you automate the process of identifying the most appropriate reviewers for each PR. This minimizes delays and ensures that each PR is examined by someone with domain-specific knowledge, elevating the quality of the review.
Increased sense of accountability: Allocating certain code sections to specific maintainers not only speeds up the review process but also instills a greater sense of responsibility. When you’re a named code owner, you’re more likely to be proactive about code quality, documentation, and other best practices.
Automated processes for greater efficiency: When you incorporate CODEOWNERS into your continuous integration, continuous delivery (CI/CD) workflows, you automate the initial step of code review. This means that the right eyes are reviewing the code quickly, which is crucial for rapid development cycles and high-velocity teams.

When you implement CODEOWNERS, you’re not merely inserting a file into your repository; you’re fundamentally improving how your project is managed, secured, and maintained.

Getting started with CODEOWNERS

If you have a repository without a CODEOWNERS file, any member can review a PR without restrictions. This means that critical pieces of code can be modified without proper oversight.

To avoid this situation, you need to create a CODEOWNERS file using the following steps:

Create a new file named CODEOWNERS inside a docs folder at the root of your project. Then add your first entry like this:

* @your-username

When someone opens a PR, @your-username will be asked to review it.

In this scenario, let’s assume you have a sample GitHub repository with the following structure:

sample-codeowners-test/
|-- docs/
| |-- CODEOWNERS
|
|-- src/
| |-- hello.py
|
|-- tests/
| |-- test_hello.py
|
|-- README.md

Please note: Putting the CODEOWNERS file in the docs folder applies to both GitHub and GitLab. Additionally, make sure you replace the @your-username with your username.

To enable or disable CODEOWNERS in your GitHub repository, you need to define a rule set. To do so, you need to go to your repository Settings and click on Rules > Rulesets in the left navigation bar. Then enable Require a pull request before merging and Require review from Code Owners :

If you’re using GitLab, you can enable CODEOWNERS on a protected branch. For more information on how to do this, refer to this GitLab documentation:

Disabling CODEOWNERS

If you disable the Require review from Code Owners option in your GitHub Settings or if you remove the Require approval from code owners in GitLab, then the PR can be merged without a review from the designated code owners. While this can speed up the merge process, it does so at the expense of code quality and security:

For all the following examples, this option is enabled.

Avoiding common pitfalls with the CODEOWNERS file

Navigating the complexities of repository management can be challenging. Avoiding missteps in the CODEOWNERS file setup is crucial for streamlined code reviews.

Create a CODEOWNERS file, but leave it empty

If you create a CODEOWNERS file but leave it empty, no one is assigned to review PRs. While this won’t block the PR process, you lose the advantages of having specified reviewers, which is generally not recommended.

In this scenario, any user with write access can approve code before it’s merged.

Define a path without any users assigned

When setting up a CODEOWNERS file, it’s essential to assign users or teams to specific paths. However, consider this improper configuration:

src/*
tests/*

Here, you define two paths in your CODEOWNERS file: tests/* and src/*. But you don’t assign any users or teams to it. In this scenario, no one is automatically assigned to review PRs affecting files in the tests and src directories. This contradicts the purpose of using a CODEOWNERS file and should be avoided.

Create a team without any members in it

In organizational setups, there may arise a need to initialize a team structure even before members are allocated. Let’s assume the CODEOWNERS file has the following content:

* @your-org/your-empty-team

If you define a team in your CODEOWNERS file (ie @your-org/your-empty-team) but that team has no members, the PR will not have any automatic reviewers. In this case, the merge is blocked unless you add a member to the team. It’s best to make sure that each team has at least one member before adding it to your CODEOWNERS file:

Using the CODEOWNERS file properly

Effective codebase management requires a deep knowledge of the tools available. This is why it’s crucial to understand how to properly utilize the CODEOWNERS file, as it facilitates precise delegation of responsibility.

Basic ownership

If you have a simple team and want one or two people to be responsible for all code, your CODEOWNERS file might look like this:

# The user @your-username is the code owner for the entire repository
* @your-username

Any PR related to changes in your code needs the approval of @your-username:

Department-based ownership

In a larger organization, you might have different departments responsible for different aspects of the code, like this:

# The Engineering department is responsible for all source code
src/* @Your-Org/EngineeringTeam

# The Quality Assurance team is responsible for all tests
tests/* @Your-Org/QATeam

# The Documentation team is responsible for the README file
/README.md @Your-Org/DocumentationTeam

Any PR related to changes under the src folder requires the approval of a member from the @EngineeringTeam. The changes in the tests folder require approval from a member of the @QATeam, and the README.md file require approval from the @DocumentationTeam:

Please note: When specifying a team, you need to make sure that this team has write access to your repository. To define the team’s name, you need to put the organization name followed by a forward slash as well as the team’s name: @Your-Org/QATeam.

Multilevel ownership

Sometimes, you’ll have a hierarchy of responsibilities. In this scenario, you can specify multiple code owners like this:

# The Core team is responsible for the entire codebase
* @Your-Org/CoreTeam

# But specific modules have additional specialized owners
src/hello.py @Your-Org/PythonExperts @Your-Org/CoreTeam

# The tests have their own owners, in addition to being under the CoreTeam
tests/* @Your-Org/TestTeam @Your-Org/CoreTeam

Here, a change to src/hello.py requires approval from someone in either @Your-Org/PythonExperts or @Your-Org/CoreTeam; whereas changes to something in the tests folder requires approval from either @Your-Org/TestTeam or @Your-Org/CoreTeam.

Exclusion rules

You can also negate ownership for specific files or folders like this:

# The Core team is responsible for the entire codebase
* @Your-Org/CoreTeam

# Except for the hello.py, which is maintained by the Python team
/src/hello.py @Your-Org/PythonTeam

In this scenario, the @Your-Org/CoreTeam is responsible for everything except src/hello.py, which is the sole responsibility of the @Your-Org/PythonTeam.

By choosing the right setup for your team’s needs, you can use the CODEOWNERS file to enforce code quality and ensure that the right people are reviewing changes to different parts of your codebase.

How team and user permissions affect CODEOWNERS

When managing code, understanding permissions is imperative. In simple terms, permissions decide who can do what in a project. Features like CODEOWNERS use these permissions to decide who can review and approve code changes. In order to use CODEOWNERS effectively, you need to know how these permissions are set and what they mean.

In GitHub, you can set permissions at an organization level, at the repository level, or within teams. Your CODEOWNERSsettings are affected by these permissions. For instance, if a user doesn’t have write access to a repo, they can’t be a code owner.

The CODEOWNERS feature doesn’t operate in isolation; it’s tied to the permissions model of the platform you’re using. Say you set a team as a code owner, but individual members of that team don’t have the necessary repository-level permissions. In this case, the CODEOWNERS setting won’t function as expected, and the team members won’t be able to act on the PR in the capacity of a code owner. The same applies to users.

In GitLab, the permission model is similar but uses different naming conventions. You have to be at least a Maintainer in a project to become a code owner. Similar to GitHub, GitLab also demands a certain level of permissions for a user to be named as a code owner. Notably, the Maintainer role allows for a broad set of permissions, including the ability to merge code and manage the repository. This is essential for code owners to effectively review and approve code changes.

If you designate a Developer in GitLab as a code owner, the setting will not take effect because the user doesn’t possess the requisite permissions to enforce code ownership rules. For more information on how it works, check out the GitLab documentation.

Regardless of the platform you’re using, understanding the interplay between CODEOWNERS and permissions is critical for setting up an effective and secure code review process.

Conclusion

In this article, you learned about the importance of implementing CODEOWNERS in your projects. Not only does it offer an extra layer of security by designating who can approve changes, but it also streamlines the PR review process and fosters a sense of ownership among project maintainers.

Additionally, integrating a CODEOWNERS file can bring about a cultural shift within your development team. It encourages clear accountability, ensuring that specific individuals or teams are responsible for particular codebases. This clarity can help prevent code rot since everyone knows who to go to for improvements or bug fixes, enhancing long-term maintainability.

Moreover, CODEOWNERS can serve as an excellent documentation tool. New team members can immediately understand which parts of the codebase are owned by which teams, easing the onboarding process and enhancing project transparency. It can also help external contributors identify whom they should contact for code-specific queries or clarifications, which fosters a more collaborative environment.

Aviator: Automate your cumbersome processes

There are 4 key components to Aviator:

MergeQueue – an automated queue that manages the merging workflow for your GitHub repository to help protect important branches from broken builds. The Aviator bot uses GitHub Labels to identify Pull Requests (PRs) that are ready to be merged, validates CI checks, processes semantic conflicts, and merges the PRs automatically.
ChangeSets – workflows to synchronize validating and merging multiple PRs within the same repository or multiple repositories. Useful when your team often sees groups of related PRs that need to be merged together, or otherwise treated as a single broader unit of change.
TestDeck – a tool to automatically detect, take action on, and process results from flaky tests in your CI infrastructure.
Stacked PRs CLI – a command line tool that helps developers manage cross-PR dependencies. This tool also automates syncing and merging of stacked PRs. Useful when your team wants to promote a culture of smaller, incremental PRs instead of large changes, or when your workflows involve keeping multiple, dependent PRs in sync.

Try it for free.

The post A modern guide to CODEOWNERS first appeared on Aviator Blog.

The post A modern guide to CODEOWNERS appeared first on Aviator Blog.

How to work with git submodules

Brian Neville-O'Neill — Tue, 31 Oct 2023 14:45:05 +0000

Git submodules allow you to include one repository inside another. This is useful when you want fine-grained control over your dependencies, or in situations where a dependency manager is not suitable. Submodules are powerful tools, and it’s worth understanding them properly before using them.

In this article, we’ll cover:

What Git submodules are
Common workflows with submodules
What they are useful for
When you shouldn’t use them

At the end of the article, you’ll also find links to further resources.

Git submodules

Imagine you are working on a text editor. You’ve implemented the basic features of viewing and editing files, and now you want to add syntax highlighting. There’s a cool library on GitHub that does exactly what you want, but it hasn’t been published to the dependency manager you use. How can you use it?

This is a situation where Git submodules might come in handy. Submodules are a feature of Git that lets you include one repository inside another. This means that you can include the syntax highlighting library in your text editor’s repo while keeping a link to the original repository so that you can receive upstream changes.

The above diagram shows what your repository structure might look like when you use submodules. The src and test directories contain your own files, but lib contains the syntax highlighter library as a submodule.

Submodules are entire Git repositories that are pinned to a specific commit. Your local copy of a repository containing a submodule will contain all of the files from the submodule, which means that you can treat it as if it were your own code. Submodules let you view, edit, and reference all of the files in the contained repository.

text-editor
├── lib
│ └── syntax-highlighter
│ ├── README.md
│ ├── docs
│ │ └── very-good-docs.md
│ └── ...
├── src
│ ├── editor.py
│ └── ...
└── test
    └── ...

Above is the file structure of our text editor repository after adding the syntax highlighting library as a submodule. All of the files from the submodule are on our filesystem and ready for us to edit them.

Workflows

Now that you’ve seen what submodules can do, the following section will take you through how to use them.

Adding a submodule to your repository

Following on from the example earlier of a syntax highlighting library, imagine that the library you want to add is at the following URL:

https://www.github.com/username/syntax-highlighter

You can add this library as a submodule to your repository by using the command:

git submodule add https://www.github.com/username/syntax-highlighter lib/syntax-highlighter

This will add two new files to your repository, .gitmodules and lib/syntax-highlighter. You can see these files using git status:

~/src/text-editor$ git status
On branch main

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
     new file: .gitmodules
     new file: lib/syntax-highlighter

.gitmodules is a simple text file that lists the submodules in your repository. You should commit this file so that other people working on your repository can also use the submodule.

lib/syntax-highlighter is a bit more complicated. Git sees this path as a file, but your filesystem sees the path as a directory. You can output what Git sees by running git diff --cached lib/syntax-highlighter:

~/src/text-editor$ git diff --cached lib/syntax-highlighter
diff --git a/lib/syntax-highlighter b/lib/syntax-highlighter
new file mode 160000
index 0000000..ac8e080
--- /dev/null
+++ b/lib/syntax-highlighter
@@ -0,0 +1 @@
+Subproject commit ac8e080ae2ba4c582eb5842139ab7e5082b4cff0

As shown in the diff above, Git sees the submodule as a file containing the commit ID currently tracked by the submodule. By default, this will be the latest commit to the default branch, which is usually main on newer Git repositories and master on older ones.

However, if you look at the submodule on the filesystem using something like ls, you’ll see that it’s a directory:

~/src/example$ ls lib/syntax-highlighter
README.md docs src test

What’s more, this directory is actually a Git repository in its own right! You can run things like git status and even edit the code in it.

Cloning a repository that contains a submodule

Git stores each submodule as an entry in .gitmodules and a file in the repo that describes what commit the submodule points to. As a result, when you clone a repo, you need to do a little extra work to download the code for the submodule into your local copy.

Let’s say you’ve cloned the text-editor repo from earlier:

git clone https://github.com/username/text-editor

If you were then to examine lib/syntax-highlighter, you’d find that it’s just an empty directory.

~/src/text-editor$ less lib/syntax-highlighter/
lib/syntax-highlighter/ is a directory

To populate lib/syntax-highlighter with the submodule’s code, you need to run git submodule update --init --recursive.

~/src/text-editor$ git submodule update --init --recursive
Submodule 'lib/syntax-highlighter' (https://github.com/username/syntax-highlighter.git) registered for path 'lib/syntax-highlighter'
Cloning into '/home/username/src/text-editor/lib/syntax-highlighter'...
Submodule path 'lib/syntax-highlighter': checked out '55086f1cb2ee8294d3354805be941171c287557d'

This is a convenient shorthand for git submodule init followed by git submodule update. If your submodules have submodules then this command will also initialize those recursively. init figures out where the submodule comes from and update downloads its contents.

An alternative workflow is to use git clone --recurse-submodules. This is an even shorter shorthand that is equivalent to a git clone, git submodule init, and git submodule update.

Editing a submodule’s code

Submodules are complete Git repositories in their own right. This means that you can use them exactly as you would any other Git repository. To illustrate this point, let’s walk through making a change to a submodule in our repository.

Imagine that you want to add a line to the syntax-highlighter library to let it support Python. We can make that change in our favorite text editor (possibly the one we’re building!) and then see the change with git diff:

~/src/text-editor/lib/syntax-highlighter$ git diff
diff --git a/src/supported-languages.txt b/src/supported-languages.txt
index ad2c90d..f4311cb 100644
--- a/src/supported-languages.txt
+++ b/src/supported-languages.txt
@@ -2,3 +2,4 @@ javascript
 markdown
 java
 c++
+python

Note the path in the terminal prompt: ~src/text-editor/lib/syntax-highlighter. We are making this change inside the submodule, not inside the original syntax-highlighter repository.

After making the change, we can do our usual git add, git commit, and voila! We have edited our submodule. You can see this change in the text-editor repository by running git diff lib/syntax-highlighter:

~/src/text-editor$ git diff lib/syntax-highlighter/
diff --git a/lib/syntax-highlighter b/lib/syntax-highlighter
index 8b6e157..55086f1 160000
--- a/lib/syntax-highlighter
+++ b/lib/syntax-highlighter
@@ -1 +1 @@
-Subproject commit 8b6e157f0fb785c619b99373bb474e03b1b72f54
+Subproject commit 55086f1cb2ee8294d3354805be941171c287557d

Note that this diff just updates the commit ID that the submodule refers to. The actual changes to the submodule are not recorded in the parent repository. This leads to a really important point: to make changes to a submodule, you need push access to the original repository. Otherwise, the changes would be reflected in your local copy of the submodule, but nowhere else.

If you didn’t create the submodule, and therefore don’t have push access, that’s ok! You just need to fork the original repository and then use your fork as the submodule’s URL.

Pulling upstream changes into a submodule

Submodules maintain a link to the upstream repository that they originate from. You can use this link to pull upstream changes.

Imagine that after you added Python support to the syntax highlighting library, you hear that the maintainers have added TypeScript support. This sounds like a useful feature to include in your text editor and so you want to pull their changes. The first step is to cd into the submodule and fetch the changes:

~/src/text-editor$ cd lib/syntax-highlighter/
~/src/text-editor/lib/syntax-highlighter$ git fetch
remote: Enumerating objects: 7, done.
remote: Counting objects: 100% (7/7), done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 4 (delta 0), reused 4 (delta 0), pack-reused 0
Unpacking objects: 100% (4/4), 419 bytes | 419.00 KiB/s, done.
From github.com/username/syntax-highlighter
 + 49301eb...54f7bbb main -> origin/main

It’s important to cd to the submodule directory first because, otherwise, you will fetch changes for your parent repository. The git fetch shows that main has been updated on the remote repository.

The changes that we want to pull in are on the main branch, so we’ll need to merge them into our own branch. We can use git merge for this:

~/src/text-editor/lib/syntax-highlighter$ git merge origin/main
Auto-merging src/supported-languages.txt
CONFLICT (content): Merge conflict in src/supported-languages.txt
Automatic merge failed; fix conflicts and then commit the result.

Oh no! There’s a merge conflict with our branch. Thankfully in this case it’s quite small:

javascript
markdown
java
c++
<<<<<<< HEAD
python
=======
typescript
>>>>>>> origin/main

In this case, we want to keep both changes and so we can just delete the merge conflict markers. We can now add, commit and push this change to our remote.

~/src/text-editor/lib/syntax-highlighter$ git add src/
~/src/text-editor/lib/syntax-highlighter$ git commit
[add-python 98d5210] Merge remote-tracking branch 'origin/main' into add-python
~/src/text-editor/lib/syntax-highlighter$ git push
Enumerating objects: 10, done.
Counting objects: 100% (10/10), done.
Delta compression using up to 12 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (4/4), 500 bytes | 500.00 KiB/s, done.
Total 4 (delta 0), reused 0 (delta 0)
To github.com/username/syntax-highlighter.git
   55086f1..98d5210 add-python -> add-python

The ability to edit the code of submodules is both their most powerful feature and their most dangerous. Maintaining your own branch tangential to the main branch of a library is incredibly useful, but be prepared to face merge conflicts.

What are submodules useful for?

Below are a couple of examples of when you might want to use submodules over a dependency manager or other solution.

Libraries not in your dependency manager

Not every library is available through a dependency manager, and no dependency manager has every library. If your dependency manager doesn’t support a certain library, then submodules can help you include it in your project.

In this case, you should weigh up the work of maintaining a submodule against the work of adding that library to your dependency management system. Remember that submodules need to be manually updated.

Editable libraries that track upstream

Dependency managers, for the most part, aren’t designed for you to modify the dependencies that they manage. If you want to make changes to a library that you depend on, then submodules might be a good solution.

Submodules keep a link to the upstream code. This means that you can still pull in the latest security and bug-fix updates from the library you depend on. If you were to just copy and paste the code into your repository, getting updates from upstream would become a lot harder.

An alternative in this situation is to try and merge your changes to the upstream repository. However, this isn’t always practical. There might be license issues, your changes might not be accepted, and even if they are you will likely have to wait a while before they get merged.

Internal libraries

It’s not always OK to publish libraries that are developed within your organization externally due to intellectual property and copyright concerns. Internal package mirrors are one solution to this problem, as they allow you to publish packages within your organization. Submodules can be a lot simpler to manage, however, and you should weigh up the cost of keeping a submodule up-to-date against the cost of maintaining a package mirror.

When not to use submodules

Submodules are powerful, but they come with some caveats. For starters, submodules don’t have automatic update mechanisms like dependency managers do.

If you add a submodule to your project, then you become responsible for keeping it up to date, whereas if you install a dependency with a dependency manager, the dependency manager can automatically keep the package on the latest version.

Git doesn’t download the contents of a submodule by default. This is not obvious to developers who haven’t worked with submodules before and can become a trip hazard for your project. If you use submodules in your project, then it’s worth thoroughly documenting development workflows in contributing.md or similar.

Submodules bring increased complexity to your development workflow, so it’s only worth using them if you need to. If a dependency manager will satisfy your use case, then consider using it over submodules.

Resources

Aviator: Automate your cumbersome processes

There are 4 key components to Aviator:

MergeQueue – an automated queue that manages the merging workflow for your GitHub repository to help protect important branches from broken builds. The Aviator bot uses GitHub Labels to identify Pull Requests (PRs) that are ready to be merged, validates CI checks, processes semantic conflicts, and merges the PRs automatically.
ChangeSets – workflows to synchronize validating and merging multiple PRs within the same repository or multiple repositories. Useful when your team often sees groups of related PRs that need to be merged together, or otherwise treated as a single broader unit of change.
TestDeck – a tool to automatically detect, take action on, and process results from flaky tests in your CI infrastructure.
Stacked PRs CLI – a command line tool that helps developers manage cross-PR dependencies. This tool also automates syncing and merging of stacked PRs. Useful when your team wants to promote a culture of smaller, incremental PRs instead of large changes, or when your workflows involve keeping multiple, dependent PRs in sync.

Try it for free.

The post How to work with git submodules first appeared on Aviator Blog.

The post How to work with git submodules appeared first on Aviator Blog.

Modeling a merge queue with TLA+

Brian Neville-O'Neill — Fri, 27 Oct 2023 18:41:58 +0000

When building a complex software system, it is hard to reason its behavior. Formal methods are a computer science research area that assists this situation by using a mathematical basis.

Model checking is one of the formal method techniques. By creating a small version of a system, it explores possible system states and checks if its desired properties are satisfied. Computer science students and graduates might be familiar with model-checking tools such as Alloy, SPIN, and NuSMV.

TLA+ is a specification language used for model checking created by Leslie Lamport. It is known for industrial usage in companies like Microsoft and AWS. In this article, we use TLA+ to create a basic merge queue system.

TLA+

TLA+ was created by Leslie Lamport. You might have heard of his other works such as Lamport Clock and Paxos. The language is used for system specification; you write the system state and processes that interact with the state.

With this description, you might imagine that it is like a database schema and a programming language. To some degree it is correct. Both are used for describing a system. Specification languages, however, are specialized to describe expected “properties” of systems.

You can think of properties as features of a system. Let’s take a merge queue as an example. Merge queue is a queueing system that takes a pull request one by one, tests them, and merges them into the mainline in order. In this system, you expect that a PR is merged in a queueing order, and a PR gets rejected when a test fails.

When writing such a system, you can run a few test cases to see if it’s merging PRs in order. This is limited in the sense that it only tests certain situations. There can be a timing bug in that a PR gets merged earlier than previous PRs.

Model checkers like TLA+ address this problem by doing an exhaustive search. Any non-trivial system has way larger state space, so we need to write a smaller model that captures the core part of the system. We can get insights by formally describing a system or describing the desired property, and the model checkers assist us with their consistency.

TLA+ itself is a specification language, but there is another language called PlusCal that is close to programming languages. Specifications written in PlusCal can be translated into TLA+. For most software engineers, PlusCal would be easier to use. There are some good TLA+ and PlusCal tutorials. The author used Learn TLA+. In addition to TLA+’s IDE, there is also VSCode extension.

Modeling a bare-bones merge queue

Let’s start with a small merge queue system. In this system, we want to model the following actors:

Developers who enqueue PRs into the system.
CI system that tests a PR.
Merge queue system that merges a tested PR.

In this first merge queue system, we ignore the “queue” part and merge the first PR that finished testing. Later we will add the “queue” part.

---- MODULE mergequeue ----
EXTENDS TLC, Sequences, Integers, FiniteSets

PRNumber == 1..3
PRState == {
    "pending",
    "queued-waiting-validation",
    "queued-validated",
    "merged"
}

(* --algorithm mergequeue

variables
    prs = [
        prn in PRNumber |->
        [
           state |-> "pending"
        ]
    ]

define
    Merged == <> A idx in PRNumber :
        prs[idx]["state"] = "merged"
end define;

fair process worker in {"w1", "w2"}
begin
    ProcessPR:
        with prn in PRNumber do
            await prs[prn]["state"] = "queued-validated";
            prs[prn]["state"] := "merged";
            time := time + 1;
        end with;
        goto ProcessPR;
end process;

fair process queuer in {"q1", "q2"}
begin
    QueuePR:
        with prn in PRNumber do
            await prs[prn]["state"] = "pending";
            prs[prn]["state"] := "queued-waiting-validation";
        end with;
        goto QueuePR;
end process;

fair process ci_worker in {"ci1", "ci2"}
begin
    RunCI:
        with prn in PRNumber do
            await prs[prn]["state"] = "queued-waiting-validation";
            prs[prn]["state"] := "queued-validated";
        end with;
        goto RunCI;
end process;

end algorithm; *)

There are 6 processes and 3 pull requests in the system. They are working in parallel and eventually, they get merged. As a property, it defines one that eventually all PRs get merged. This is a very trivial system, but it’s a good starting point.

Running this passes the validation. To test if the validation is actually validating what we want, we can change the merged property to expect everything to be “queued-validated”. Running that version produces a counter-example.

At step 10, it finds all states to be “merged”, not “queued-validated”.

Let’s modify the model so that it can handle test failures. In this modification, the CI system produces either failed or passed, and the merge queue system marks the PR to be blocked for the failed ones.

PRState == {
    "pending",
    "queued-waiting-validation",
    "queued-validated",
    "queued-failed",
    "merged",
    "blocked",
}

The CI workers nondeterministically mark the PRs as failed or passed.

RunCI:
    with prn in PRNumber do
        await prs[prn]["state"] = "queued-waiting-validation";
        either
            prs[prn]["state"] := "queued-validated";
        or
            prs[prn]["state"] := "queued-failed";
        end either;
    end with;
    goto RunCI;

The merge queue workers merge the PRs or mark them as blocked.

ProcessPR:
    with prn in PRNumber do
        either
            await prs[prn]["state"] = "queued-validated";
            prs[prn]["state"] := "merged";
        or
            await prs[prn]["state"] = "queued-failed";
            prs[prn]["state"] := "blocked";
        end either;
    end with;
    goto ProcessPR;

Running this modified model will actually produce a counter-example.

We need to change the expected property for the model.

MergedOrBlocked == <> A idx in PRNumber :
    prs[idx]["state"] in {"merged", "blocked"}

In this model, eventually, every PR gets merged or blocked.

Adding the “queue” part to the merge queue

The described merge queue system merges the finished PR and rejects them if the tests fail, but they are merged out of order. We want them to get merged in the queuing order. Let’s add the queuing part to the system.

In this case, we change the MergeQueue to behave like this:

MergeQueue system merges a PR if the PR that passed the test and the previously queued PRs are merged.

To represent the queue order, we need to add a concept of “time”. Let’s add that to PRs.

variables
    time = 1,
    prs = [
        prn in PRNumber |->
        [
           state |-> "pending",
           queuedAt |-> 0
        ]
    ]

And queuing a PR sets this queued at and increments the clock.

QueuePR:
    with prn in PRNumber do
        await prs[prn]["state"] = "pending";
        prs[prn]["state"] := "queued-waiting-validation" || prs[prn]["queuedAt"] := time;
        time := time + 1;
    end with;
    goto QueuePR;

How do we make the merge queue workers merge only if the prior PRs get merged? Let’s create a predicate to test if prior PRs are already merged.

PriorPRMerged(prn) ==
    A idx in PRNumber:
        (/ prs[idx]["queuedAt"] # 0
         / prs[idx]["queuedAt"] < prs[prn]["queuedAt"])
            => prs[idx]["state"] = "merged"

This condition checks if the PR’s queuedAt is already filled and it’s earlier than the PR in question. If so, it should be marked “merged”. Otherwise, this condition won’t become true.

With this condition, we can guard the merge process.

await prs[prn]["state"] = "queued-validated" / PriorPRMerged(prn);

This modification will make the queue stuck. Why? Let’s see the counter example produced by the model checker.

In the counter-example, the PRs are queued from 1 to 3. However, the first PR gets blocked. Other PRs are stuck because PriorPRMerged condition will never be satisfied.

What do we want to do in this situation? We can remove the blocked PR from the queue and let the other PRs get merged. This can get more complicated if the MergeQueue system supports ChangeSets, where the system merges related PRs together. This is not in the current scope, so let’s punt on that. Let’s remove the blocked PR from the queue.

await prs[prn]["state"] = "queued-failed";
prs[prn]["state"] := "blocked" || prs[prn]["queuedAt"] := 0;

Changing this makes the model checker happy.

As we see in this extension, the model checker presents a possible system state that won’t satisfy the expected property. In order to fix the problem, we need to think about what extra behavior is needed for the system. In this case, if a PR gets blocked by a CI, it can clog the entire queue.

This time, we simply remove the offending PR from the queue, but there can be other actions, such as enqueuing the blocked PR to the back of the queue. This iterative process inspires you to the high-level spec of the system in a verifiable way.

Final remarks

We went through a system modeling process by creating a small merge queue system. Starting from a small one, we expand it to have more specifications. In the process, we discovered an example situation where an expected property won’t be held, and what can be missing in the system. The resulting system is still small, but this is a good starting point. We can iterate the process until the system has enough features.

Model checking is relatively easy to start. For people who are more interested in this area, we suggest reading Software Abstractions. You should be able to find relevant classes in undergraduate CS courses in universities. Some model checkers are based on SAT solvers. Occasionally, you will find a problem that can be converted into a SAT problem in software engineering. Adding this as a toolbox allows you to have more options for problems at your hand.

TLA+ is fun and easy to learn. AWS reports that engineers at various levels could get useful results in 2-3 weeks after they started learning. The author of this article also learned TLA+ for the first time and was able to write this small MergeQueue model in half a day. Being able to get a useful result in a few weeks is totally believable. If you haven’t tried it out, we recommend it.

Aviator: Automate your cumbersome processes

There are 4 key components to Aviator:

MergeQueue – an automated queue that manages the merging workflow for your GitHub repository to help protect important branches from broken builds. The Aviator bot uses GitHub Labels to identify Pull Requests (PRs) that are ready to be merged, validates CI checks, processes semantic conflicts, and merges the PRs automatically.
ChangeSets – workflows to synchronize validating and merging multiple PRs within the same repository or multiple repositories. Useful when your team often sees groups of related PRs that need to be merged together, or otherwise treated as a single broader unit of change.
TestDeck – a tool to automatically detect, take action on, and process results from flaky tests in your CI infrastructure.
Stacked PRs CLI – a command line tool that helps developers manage cross-PR dependencies. This tool also automates syncing and merging of stacked PRs. Useful when your team wants to promote a culture of smaller, incremental PRs instead of large changes, or when your workflows involve keeping multiple, dependent PRs in sync.

Try it for free.

The post Modeling a merge queue with TLA+ first appeared on Aviator Blog.

The post Modeling a merge queue with TLA+ appeared first on Aviator Blog.

How to optimize Jenkins pipeline performance

Brian Neville-O'Neill — Thu, 26 Oct 2023 19:11:13 +0000

Jenkins is a popular open-source automation server that is widely used for building, testing, and deploying code. Jenkins pipelines, which allow you to define and automate your entire build and deployment process, are a powerful feature of Jenkins. When you’re building a CI/CD pipeline with Jenkins, optimizing performance becomes crucial to ensure efficiency and speed in your CI/CD pipeline.

In this article, we will explore various strategies and techniques to optimize the performance of your Jenkins pipeline.

Why optimize?

Optimizing your Jenkins pipeline offers several benefits, including:

Faster build times: Faster pipelines mean quicker feedback for developers, which can lead to more agile and efficient development cycles
Reduced resource consumption: Optimized pipelines consume fewer resources, which can translate to cost savings, especially in cloud-based CI/CD environments
Improved reliability: Well-optimized pipelines are less prone to failures, leading to a more reliable CI/CD process

Let’s dive into the steps you can take to achieve these benefits.

Best practices for performance optimization

Whether you’re a seasoned Jenkins administrator or just beginning to harness its power, it’s crucial to embrace best practices for performance optimization that can help you streamline your processes, minimize bottlenecks, and maximize the efficiency of your CI/CD workflows.

Here, we will explore a comprehensive set of best practices, strategies, and techniques to fine-tune your Jenkins environment. From optimizing hardware resources and pipeline design to utilizing plugins effectively, we will dive into the world of Jenkins performance optimization, equipping you with the knowledge and tools you need to ensure your Jenkins server operates at its peak potential.

Before we get into the optimization technique, I will provide a table that shows the impact and difficulty level of each technique so you can have a little imagination of what it will be like before getting in.

	Impact	Difficulty
1. Keep Builds Minimal at the Master Nodes	⭐⭐⭐⭐	⭐⭐
2. Plugin Management	⭐⭐⭐	⭐⭐⭐
3. Workspace and Build Optimization	⭐⭐⭐	⭐⭐⭐
4. Use the “Matrix” and “Parallel” steps	⭐⭐⭐⭐	⭐⭐⭐⭐
5. Job Trigger Optimization	⭐⭐	⭐⭐⭐
6. Optimize Docker Usage	⭐⭐⭐⭐	⭐⭐⭐⭐
7. Workspace and Artifact Caching	⭐⭐⭐	⭐⭐⭐
8. Use Monitoring Tools	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐

Keep builds minimal at the master nodes

A key strategy is to keep builds minimal at the master node. The Jenkins master node is the control center of your CI/CD pipeline, and overloading it with resource-intensive builds can lead to performance bottlenecks, slower job execution, and reduced overall efficiency. To address this challenge and ensure a well-optimized Jenkins environment, it’s essential to distribute builds across multiple nodes and leverage the full power of your infrastructure.

The Jenkins master node should primarily serve as an orchestrator and controller of your CI/CD pipeline. It is responsible for managing jobs, scheduling builds, and maintaining the configuration of your Jenkins environment.

To keep builds minimal at the master node, we can use distributed builds.

Distributed Builds in Jenkins

Distributed builds in Jenkins involve the parallel execution of jobs on multiple agents, taking full advantage of your infrastructure resources. This approach is particularly beneficial when dealing with resource-intensive tasks, large-scale projects, or the need to reduce build times to meet tight delivery deadlines.

By distributing builds across multiple nodes in Jenkins, you can optimize performance, reduce build times, and enhance the overall efficiency of your CI/CD pipeline, ultimately delivering software faster and more reliably.

Here’s a sample Jenkins Pipeline script to demonstrate a simple distributed build setup:

pipeline {
    agent none
    stages {
        stage('Build on Linux Agent') {
            agent { label 'linux' }
            steps {
                sh 'make'
            }
        }
        stage('Build on Windows Agent') {
            agent { label 'windows' }
            steps {
                bat 'msbuild myapp.sln'
            }
        }
    }
}

In this example, the pipeline defines two stages, each running on a specific agent labeled ‘linux’ or ‘windows’, illustrating the distribution of build tasks across different agents.

Plugin management

Jenkins plugins extend the functionality of the platform, allowing you to add various features and integrations. However, an excessive number of plugins or outdated ones can lead to reduced performance and potential compatibility issues. Here are some best practices for optimizing performance through efficient plugin management:

Keep Plugins up to date : Regularly updating your Jenkins plugins is crucial to ensure you have the latest features, bug fixes, and security enhancements. Outdated plugins may contain vulnerabilities or be incompatible with newer Jenkins versions, leading to performance issues or security risks.
Uninstall unnecessary plugins: Just as important as keeping plugins up-to-date is eliminating unnecessary ones. Over time, Jenkins instances tend to accumulate plugins that are no longer needed. These unused plugins can increase overhead and slow down your pipeline execution. Regularly review your installed plugins and remove any that are obsolete or no longer in use.
Use plugin managers: Jenkins offers several plugin management tools that can help streamline the process. Consider using plugin managers.
Test plugin updates: Before updating a plugin, testing it in a non-production environment is essential. Plugin updates can sometimes introduce compatibility issues or unexpected behavior.

Workspace and build optimization

The workspace is where your pipeline jobs execute, and ensuring it’s lean and well-organized can lead to faster builds and reduced resource consumption. Here are some strategies to achieve workspace and build optimization:

Minimize workspace size: Use the “cleanWs” step within your pipeline to remove unnecessary files from the workspace. This step helps keep the workspace clean and reduces the storage and I/O overhead, leading to faster builds. Be selective in what you clean to ensure essential artifacts and build dependencies are retained.
Implement reusable pipeline libraries: One common source of inefficiency in Jenkins pipelines is redundant code. If you have multiple pipelines with similar or overlapping logic, consider implementing reusable pipeline.
Artifact caching: Implement artifact caching mechanisms to store and retrieve frequently used dependencies.
Optimize build steps: Review and optimize the individual build steps within your pipeline. This includes optimizing scripts, minimizing the use of excessive logs, and using efficient build tools and techniques. Reducing the duration of each build step can collectively contribute to faster overall pipeline execution.

Use the “matrix” and “parallel” steps

Parallelism and matrix can be used in Jenkins to optimize and streamline your continuous integration (CI) and continuous delivery (CD) pipelines. They help in distributing and managing tasks more efficiently, especially when dealing with a large number of builds and configurations. Here’s how parallelism and matrices can be used for optimization in Jenkins:

Parallelism : Jenkins supports parallel execution of tasks within a build or pipeline. This is particularly useful for tasks that can be executed concurrently, such as running tests on different platforms or building different components of an application simultaneously.

Here is an example of how to implement parallelism in Jenkins:

pipeline {
agent none
stages {
stage('Build And Test') { // Rename the stage to provide a more descriptive name
parallel {
stage('macos-chrome') {
agent { label 'macos-chrome' }
stages {
stage('Build') { // Build stage for macOS Chrome
steps {
sh 'echo Build for macos-chrome'
}
}
stage('Test') { // Test stage for macOS Chrome
steps {
sh 'echo Test for macos-chrome'
}
}
}
}
stage('macos-firefox') {
agent { label 'macos-firefox' }
stages {
stage('Build') { // Build stage for macOS Firefox
steps {
sh 'echo Build for macos-firefox'
}
}
stage('Test') { // Test stage for macOS Firefox
steps {
sh 'echo Do Test for macos-firefox'
}
}
}
}
stage('macos-safari') {
agent { label 'macos-safari' }
stages {
stage('Build') { // Build stage for macOS Safari
steps {
sh 'echo Build for macos-safari'
}
}
stage('Test') { // Test stage for macOS Safari
steps {
sh 'echo Test for macos-safari'
}
}
}
}
stage('linux-chrome') {
agent { label 'linux-chrome' }
stages {
stage('Build') { // Build stage for Linux Chrome
steps {
sh 'echo Build for linux-chrome'
}
}
stage('Test') { // Test stage for Linux Chrome
steps {
sh 'echo Test for linux-chrome'
}
}
}
}
stage('linux-firefox') {
agent { label 'linux-firefox' }
stages {
stage('Build') { // Build stage for Linux Firefox
steps {
sh 'echo Build for linux-firefox'
}
}
stage('Test') { // Test stage for Linux Firefox
steps {
sh 'echo Test for linux-firefox'
}
}
}
}
}
}
}
}

This Jenkins pipeline is designed to automate the build and test processes for a software project across different operating systems and web browsers. The pipeline consists of several stages, each of which serves a specific purpose.

In the first stage, “build and test,” the pipeline leverages parallel execution to run multiple sub-stages concurrently. These sub-stages are responsible for building and testing the software on various configurations. There are dedicated sub-stages for different combinations of the operating system and web browser, including macOS with Chrome, macOS with Firefox, macOS with Safari, Linux with Chrome, and Linux with Firefox.

Matrix build : Jenkins provides a feature called “Matrix build” that allows you to define a matrix of parameters and execute your build or test configurations across different combinations. This is useful for testing your software on various platforms, browsers, or environments in parallel. Here’s an example of how a matrix pipeline can be implemented:


pipeline {
    agent none
    stages {
      stage('BuildAndTest') { // This is the main stage that includes a matrix build and test configuration.
        matrix {
          agent { // This defines the agent label for each matrix configuration.
            label "${PLATFORM}-${BROWSER}"
          }
          axes {
            axis { // This axis defines the PLATFORM variable with possible values 'linux' and 'macos'.
              name 'PLATFORM'
              values 'linux', 'macos'
            }
            axis { // This axis defines the BROWSER variable with possible values 'chrome', 'firefox', and 'safari'.
              name 'BROWSER'
              values 'chrome', 'firefox', 'safari'
            }
          }
          excludes {
            exclude { // This specifies an exclusion for the matrix based on specific PLATFORM and BROWSER values.
              axis {
                name 'PLATFORM'
                values 'linux'
              }
              axis {
                name 'BROWSER'
                values 'safari'
              }
            }
          }
          stages {
            stage('Build') { // This stage represents the build process for the selected matrix configuration.
              steps {
                sh 'echo Do Build for $PLATFORM-$BROWSER'
              }
            }
            stage('Test') { // This stage represents the test process for the selected matrix configuration.
              steps {
                sh 'echo Do Test for $PLATFORM-$BROWSER'
              }
            }
          }
        }
      }
    }
  }

Inside the BuildAndTest stage, a matrix is defined using the matrix block. This matrix configuration involves different axes, PLATFORM and BROWSER, which specify combinations of operating systems (linux and macOS) and web browsers (Chrome, Firefox, and Safari).

Certain combinations, such as linux with safari, are excluded, meaning they wont be part of the automated tests. For each combination, there are two sub-stages:BuildandTest. In theBuildsub-stage, a command is executed to build the software for the specific combination, and in theTest` sub-stage, a test command is executed to verify the software’s functionality. The pipeline will run these sub-stages in parallel for all valid combinations, resulting in efficient testing and building across different environments.

By using parallelism and matrix combinations in Jenkins, you can significantly reduce the time it takes to test your software or run various configurations, thereby optimizing your CI/CD pipeline.

Job trigger optimization

Continuous integration pipelines can be triggered by various events, such as code commits, pull requests, or scheduled runs. However, triggering jobs too frequently can strain your Jenkins server and slow down the overall process. To implement this you can:

Consider using a sensible trigger strategy, e.g., triggering a job only on important events like code merges to the main branch. You can configure webhooks or use the Jenkinsfile to control the trigger conditions.
Jenkins provides a “quiet period” feature that introduces a delay before starting a job after a trigger event. This can be particularly useful to batch multiple job executions triggered by consecutive commits. Adjust the quiet period to allow Jenkins to batch related jobs together, reducing the frequency of builds and optimizing resource usage.

Optimize Docker usage

If your Jenkins pipeline utilizes Docker containers for building and testing, be mindful of the number of containers that run simultaneously. Running too many containers concurrently can exhaust system resources and impact performance.

Adjust your Jenkins configuration to limit the maximum number of containers that can run concurrently based on the available system resources.

Use Docker Image Caching

Docker image caching can significantly reduce the time it takes to set up the necessary environment for your builds. When a Docker image is pulled, it is stored locally, and subsequent builds can reuse this cached image.

Implement a Docker image caching strategy in your Jenkins pipelines to minimize the need for frequent image pulls, especially for base images and dependencies that don’t change often. This can significantly speed up your build process.

Workspace and artifact caching

Workspace and artifact caching are essential optimization techniques in Jenkins that can significantly improve build and deployment efficiency. Workspace caching helps reduce the time required to check out and update source code repositories, while artifact caching helps speed up the distribution of build artifacts.

Workspace caching:

Workspace caching allows Jenkins to cache the contents of a workspace so that when a new build is triggered, it can reuse the cached workspace if the source code has not changed significantly. This is particularly useful for large projects with dependencies and libraries that do not change frequently.

Here’s an example Jenkinsfile script that demonstrates workspace caching using the Pipeline Caching plugin:

pipeline { agent any options { // Configure workspace caching skipDefaultCheckout() cache(workspace: true, paths: ['path/to/cache']) } stages { stage('Checkout') { steps { script { // Checkout source code manually checkout scm } } } stage('Build') { steps { // Your build steps here } } } }

Artifact Caching:

Artifact caching involves caching build artifacts (e.g., compiled binaries, build outputs) so that subsequent builds can reuse them rather than recompiling or regenerating them. This can save a significant amount of time and resources.

To cache build artifacts, you can use the “stash” and “unstash” steps in your Jenkinsfile:

`
pipeline {
agent any
stages {
stage('Build') {
steps {
// Build your project
sh 'make'

            // Stash the build artifacts
            stash name: 'my-artifacts', includes: 'path/to/artifacts/**'
        }
    }
    stage('Test') {
        steps {
            // Unstash and use the cached artifacts
            unstash 'my-artifacts'

            // Run tests using the cached artifacts
        }
    }
}

}
`

Use monitoring tools:

Monitoring tools are essential for optimizing Jenkins pipelines and ensuring they run smoothly and efficiently. They provide insights into the performance and health of your Jenkins infrastructure, helping you identify and address bottlenecks and issues. Here are a few monitoring tools you can use in Jenkins:

Prometheus and Grafana: Prometheus is a popular open-source monitoring and alerting toolkit, and Grafana is a visualization platform that works well with Prometheus. You can use the “Prometheus Metrics Plugin” in Jenkins to expose Jenkins metrics to Prometheus, and then create dashboards in Grafana to visualize these metrics.
Jenkins monitoring plugin: The Jenkins Monitoring Plugin allows you to monitor various aspects of Jenkins, including build queue times, node usage, and system load. It provides useful information for optimizing Jenkins infrastructure.
SonarQube integration: SonarQube is a tool for continuous inspection of code quality. Integrating SonarQube with Jenkins allows you to monitor code quality and identify areas for improvement in your projects.

Using these monitoring tools in Jenkins, you can gain insights into your pipelines’ performance and resource utilization, allowing you to make informed decisions for optimization and troubleshooting.

Conclusion

In conclusion, optimizing performance in your Jenkins pipeline is crucial for achieving faster, more efficient, and reliable continuous integration and continuous delivery processes. Jenkins is a powerful automation server, and by implementing a variety of best practices and techniques, you can ensure that it operates at its peak potential. This article has explored various strategies to achieve performance optimization in your Jenkins pipeline, particularly when publishing Docker images to DockerHub.

The benefits of optimization of the Matrix Project are evident, with faster build times, reduced resource consumption, and improved reliability being at the forefront. Ensuring that your Jenkins pipeline operates efficiently can lead to more agile development cycles, cost savings, and a dependable CI/CD process.

Aviator: Automate your cumbersome processes

There are 4 key components to Aviator:

MergeQueue – an automated queue that manages the merging workflow for your GitHub repository to help protect important branches from broken builds. The Aviator bot uses GitHub Labels to identify Pull Requests (PRs) that are ready to be merged, validates CI checks, processes semantic conflicts, and merges the PRs automatically.
ChangeSets – workflows to synchronize validating and merging multiple PRs within the same repository or multiple repositories. Useful when your team often sees groups of related PRs that need to be merged together, or otherwise treated as a single broader unit of change.
TestDeck – a tool to automatically detect, take action on, and process results from flaky tests in your CI infrastructure.
Stacked PRs CLI – a command line tool that helps developers manage cross-PR dependencies. This tool also automates syncing and merging of stacked PRs. Useful when your team wants to promote a culture of smaller, incremental PRs instead of large changes, or when your workflows involve keeping multiple, dependent PRs in sync.

Try it for free.

The post How to optimize Jenkins pipeline performance first appeared on Aviator Blog.

The post How to optimize Jenkins pipeline performance appeared first on Aviator Blog.

What is build failure rate?

Brian Neville-O'Neill — Fri, 13 Oct 2023 19:38:56 +0000

During the software build process, you convert your code into computer-understandable format, depending on the language. Javascript and related libraries are condensed back into vanilla format. Rust and Java code is compiled into machine language before committing.

Build failure rate is a metric that measures the percentage of build failures during your software build process. You should note that there are important uses for build failure rates:

It helps you avoid harmful software user experience
Build failure rates tell you more about your development efficiency
It enables you to refactor code where needed to increase software efficiency
It gives you the confidence to release quality software when the failure rate is low or non-existent

In this article, we will focus on the following:

Factors affecting build failure rates
How to measure the build failure rate in your software build process
Effects of build failure rates
Strategies to reduce build failure rates in your development process

Factors affecting build failure rate

Code Quality

The quality of your code directly affects build failure rate. Let’s say you are building a house using blocks and don’t adequately align the blocks you use. There is a high chance that defects will appear later in the building. If you had done it neatly, that wouldn’t be the case.

If your code quality is terrible, it will result in bugs and defects, which obviously affects build failure rate. Good code quality should meet the following metrics:

Clarity
Reusability
Security
Testability

You should note that robust code is the foundation of a stable build.

Third-Party Integrations

Another factor that affects the build failure rate in your software build process is how you manage your dependencies. Since these external libraries are essential to your software development, you must ensure you appropriately handle them.

A lack of third-party management discipline causes a high failure rate with time. Here are some good practices to avoid a build failure rate:

Automated dependency update: Outdated dependencies are one of the causes of build failure. To avoid this, updating dependency versions would help you avoid causing changes that could cause build failures. To this, you should have your dependency versions updated automatedly.
Metadata Tracking: Using incorrect dependency metadata creates a situation where the wrong installation is done. Doing this can introduce failures into your build. So, keeping track of the metadata helps prevent this since the correct versions are installed.
Using a package manager: To avoid each developer on your team using their dependencies inconsistently. Introducing a centralized management model will help create consistency when using dependencies and reduce the potential build failure rate.

A hypothetical example: You had developed software using the available dependency update “X” at the time, and during your build process, another update, “Y,” became available, which made “X” have deficiencies. A build failure may likely happen if your dependency update isn’t automated.

If you don’t apply best practices when using dependencies, they can cause a high percentage of build failure in your software development process.

Infrastructure Environment

A consistent environment with defined parameters helps reduce variability and helps with configuration errors. Let’s say you use an inconsistent environment. You used a specific environment, let’s name it “A,” and later on, you use another named “B.” The errors you get in environment “A” could be entirely different in environment “B,” which could be hard to track and resolve.

You can also avoid conflicts from concurrent changes by using a monorepo. Aviator’s MergeQueue helps you maintain a monorepo without issues. Also, having a robust infrastructure environment helps your team avoid issues like server crashes, which cause build failures.

Lastly, if you use a bundled virtual environment like docker containers, you can avoid infrastructure inconsistency issues.

Measuring a Build Failure Rate

You can calculate a build failure rate using a straightforward formula: Divide the total number of build failures by the total number of attempted builds within a given time period. The resulting answer is expressed in a percentage.

For example, let’s say the total number of build failures in your build process is 30, and the total number of attempted builds is 50 within six months. To get the build failure rate, divide the total number of build failures, which is 30, by the total number of attempted builds, which is 50. Calculating this will give you a build failure rate of 60 percent.

The formula is given as:

Build failure rate% = (Number of build failures/Number of attempted builds*100

Another way you can track and report the build failure rate over time is by using tools that show you the analytical reports of failures you have. Also, there are best practices you should use when monitoring your builds over time:

Calculate the failure rate of your builds over a given period.
Monitor the failure rate for each stage of your pipeline.
Identify and monitor flaky tests separately.
Log the build failure rate you get in detail.

Measuring the build failure rate in your software development offers advantages, and analyzing this helps you achieve a stable build.

Effects of a Build Failure Rate

The effects of a build failure rate vary. The impact on your software development process could be different from another. However, these are the expected effects of a high build failure rate:

Delayed project timeline and make you miss deadlines
Increased software development costs (engineer’s time)
Negatively impact on your team’s morale and productivity
If you don’t resolve the underlying issues, you will release software with defects and bugs

Conclusion

Build failure happens during a software build process. Implementing strategies around the factors affecting build failure can help you have a low build failure rate:

Having good code quality by debugging using linter and static tools
Well-managed third-party integrations in your software development
Consistent infrastructure environment

Knowing what causes build failures, preventing them, and applying good practices will reduce the total number of failures concerning your overall attempted builds.

Aviator: Automate your cumbersome processes

There are 4 key components to Aviator:

MergeQueue – an automated queue that manages the merging workflow for your GitHub repository to help protect important branches from broken builds. The Aviator bot uses GitHub Labels to identify Pull Requests (PRs) that are ready to be merged, validates CI checks, processes semantic conflicts, and merges the PRs automatically.
ChangeSets – workflows to synchronize validating and merging multiple PRs within the same repository or multiple repositories. Useful when your team often sees groups of related PRs that need to be merged together, or otherwise treated as a single broader unit of change.
TestDeck – a tool to automatically detect, take action on, and process results from flaky tests in your CI infrastructure.
Stacked PRs CLI – a command line tool that helps developers manage cross-PR dependencies. This tool also automates syncing and merging of stacked PRs. Useful when your team wants to promote a culture of smaller, incremental PRs instead of large changes, or when your workflows involve keeping multiple, dependent PRs in sync.

Try it for free.

The post What is build failure rate? first appeared on Aviator Blog.

The post What is build failure rate? appeared first on Aviator Blog.

Embracing trunk-based development: Advantages, disadvantages, and best practices

Brian Neville-O'Neill — Thu, 12 Oct 2023 19:56:24 +0000

Trunk-based development (TBD) caters to developers working on the same codebase (trunk). As a developer, there’s a huge chance you are working with other developers on a project, merging changes to a single codebase. This means managing every change made to the source code during development. This is where version control management (VCM) practices are especially helpful.

VCM practices are vital in preserving code history, preventing errors, supporting parallel development, enabling continuous integration, enhancing code review, and more. Trunk-based development is a popular VCM practice that helps reduce the challenges associated with branch management and merge conflicts.

In this article, you will learn about the advantages, disadvantages, best practices, and the role of merge queues in trunk-based development.

What is a trunk-based development?

Trunk-based development is, quite frankly, an old practice. Its origin can be traced back to earlier version control systems like concurrent version systems (CVS) and subversion (SVN), where the prevalent philosophy advocated for everyone working on a single trunk, occasionally creating short-lived branches for purposes like bug-fixing or experimental development.

Authors like Jez Humble, co-author of DevOps Handbook and Continous Delivery, mentioned Version Control and the importance of avoiding long-lived branches in the 90s. So, what makes TBD so unique?

With TBD, developers can make frequent small changes, such as code integrations directly to the main branch or trunk, instead of creating long-lived feature branches. TBD is a type of continuous integration that prioritizes regular integration of code changes and their testing within a shared environment.

The goal is to promptly identify and address integration problems, thereby lowering the chances of such issues occurring again. This practice also shortens the time needed to introduce new features and enhances the overall quality of the codebase.

TBD is common among DevOps teams since it is mostly associated with merging and integration phases.

The significance of trunk-based development in your CI/CD Pipeline

Trunk-based workflows are great because they work seamlessly with continuous integration and continuous delivery (CI/CD) services. Here’s how it works:

Each time you make a change to the main branch, automated tests (a branch of CI) check to make sure it doesn’t break anything
After passing these tests, a pipeline can be set up to prepare the changes for the QA team to review on the staging branch
The release manager, responsible for creating new releases, can then use the main branch’s code to publish a new release based on feedback from the QA team
If any issues arise in production, a senior developer can make fixes specifically for that release

This approach keeps each release unique and doesn’t change the older release branches. As time passes, you can safely delete older release branches that are no longer needed.

The role of a merge queue in trunk-based development

Merge queue plays a crucial role in managing code changes and ensuring a streamlined and controlled process for integrating PRs into the main development branch, often called the “trunk” or “mainline.”

The role of a merge queue in TBD includes:

Centralized Integration Point: The merge queue serves as the central point where code changes from different developers or teams are merged into the main branch. This ensures that all code changes are funneled through a single point of integration, reducing integration complexities and conflicts.
Controlled Integration: The merge queue provides a controlled and orderly way to merge code changes into the trunk. This control helps prevent integration issues and conflicts that can arise when multiple developers attempt to merge their changes simultaneously.
FIFO (First-In-First-Out) Order: In a merge queue, code changes are typically merged in a first-come, first-served order. This FIFO approach ensures that code changes are integrated in the submitted sequence, preventing any individual or team from monopolizing the merge process.
Rollback Mechanism: In the event that a merged change causes unexpected issues or errors in the trunk, a merge queue may provide mechanisms to quickly roll back or revert the change, minimizing the impact on the development process.
Automated Testing and Validation: Before code changes are merged into the trunk, they typically go through a series of automated tests and validations to ensure that they meet the required quality and compatibility standards. This can include unit tests, integration tests, code reviews, and other quality checks.

Implementing trunk-based development

Trunk-based development can be really useful in various application development cases. For instance, a startup MVP for investors or a client project on Fiverr. You do not need to wait for a project admin or a senior developer to review and merge the PR before pushing your changes.

An exception is the presence of experienced developers who help eliminate the chances of build-failing changes committed to the trunk.

Here is how I would implement TBD:

Online services like Gitlab, Github, and more are needed for Git version control
You need to create three pivotal branches: the main branch (also known as the trunk), a staging branch, and a production branch. Developers commit their code changes to the main branch. A release manager can then create new releases by merging the main branch with either the staging or production branch
Code quality and integration should be prioritized if you plan to implement trunk-based development. A great way to ensure this is through the employment of a CI system. A CI system tests the modifications made by developers before changes become ready for release
A CD system takes center stage in this process. It helps during the building and deployment stages of a project in either the staging or production environment

Trunk-based development vs. feature-based/Gitflow

Both development workflows have pros and cons, but depending on your instance, you can decide which works for you.

TBD is better if you are working on a project that changes frequently and requires swift, constant deployment. Developers can seamlessly integrate small changes to the trunk. Let’s say you are developing new product features or fixing a bug, TBD is absolutely great for this kind of change. You can also perform frequent code reviews and smooth automated test integrations with TBD.

Meanwhile, feature-based/Gitflow is much more useful in long-term projects. For example, if you are developing a large e-commerce application, you should utilize Gitflow, especially if a huge development team is on board. This is because Gitflow allows developers to work on separate branches, eliminating the need for collaborations and meetings.

Advantages of trunk-based development

Let’s take a look at some of the main advantages of implementing TBD:

Simpler Codebase: With fewer long-lived branches, the codebase remains simpler and easier to understand. This reduces complexity, making it easier to maintain and troubleshoot code.
Integration with CI/CD: An important benefit of TBD is its seamless integration with CI/CD services. This fosters an agile and smooth development environment.
Faster time-to-market: Most businesses take faster time-to-market very seriously. They need to roll out new features or products as fast as possible to customers. As a developer, implementing TBD can make this happen. TBD helps reduce development and deployment time, ensuring new functionalities are delivered to end-users on time.
Improved Feedback Loop: Regular integration allows for quick feedback on the impact of code changes. Developers can assess how their modifications affect the overall system, which is valuable for iterative improvement.
Easier Debugging: When issues arise, it’s easier to identify the exact change that introduced the problem since there are fewer changes in the main branch. This simplifies debugging and troubleshooting.

Disadvantages of trunk-based development

As with any great software, implementation, or service, TBD has its advantages and disadvantages. Let’s take a look at some of its disadvantages.

Isolation Problems: Since feature branches are absent, isolating changes for testing purposes can be challenging before integration into the Trunk.
Learning Curve: Sadly, unless you are very technically inclined, wrapping your head around the ins and outs of TBD might take a while. The best way to avoid this is through training and training materials such as e-books, videos, and community support.
Code conflicts: If codes aren’t merged properly, it leads to conflicts in your main codebase (the trunk).
Dependency management: Trunk-based development can complicate the task of managing dependencies since developers cannot readily isolate various components or features.

Versioning and Rollbacks: Managing versions and rollbacks can be more complex in TBD, especially when multiple versions are under active development simultaneously.

Best practices for implementing trunk-based development

Companies like Netflix, Google, and Facebook use TBD during development. According to Google’s published Accelerate State of DevOps 2021 report, companies with higher performance are likely to have trunk-based development implemented.

Let’s take a look at some of the best practices for implementing TBD.

Automation First

To begin with, it’s important to introduce automation wherever feasible and effective. Automation should be applied in various aspects, such as software development, testing procedures, and deployment processes.

By embracing this approach, you can empower your team to carry out swift and effective iterations, thereby reducing the likelihood of any adverse impact on the primary codebase. A great automation software like Aviator is there to help you achieve this seamlessly.

Code freezes halt development. Avoid it!

Code freezes can impede the development process and cause integration issues as changes made in isolation may not smoothly align when merged into the main branch. A great way to avoid code freezes is to incentivize developers to integrate their work into the trunk when it reaches a stable state, even if it’s not entirely finished. This rapid integration helps prevent the accumulation of errors that tend to occur with prolonged waits.

In cases where it’s necessary, you can utilize feature toggles or branch-by-abstraction techniques to temporarily hide unfinished features, ensuring they don’t affect the rest of the codebase.

Pair or mob Programming?

In TBD, it’s essential to conduct code reviews promptly. While automated testing is valuable but doesn’t guarantee top-notch code quality. Therefore, employing methods like pair or mob programming to enhance team communication and facilitate immediate code review is beneficial.

A features flags management tool is the way to go

Feature management is a method for handling feature development and testing. It involves gradually releasing changes or new features to specific user groups before full deployment. This is achieved using “feature flags” that wrap new changes in inactive code paths, which can be activated when needed.

To simplify this process, consider using feature management tools like LaunchDarkly. These tools facilitate feature experimentation, A/B testing, and continuous deployment of microservices, allowing developers to combine testing with feature rollout. This approach ensures feature deployment without compromising software stability and provides the flexibility to roll back features without affecting the rest of the code in production.

Conclusion

Embracing Trunk-Based Development represents a bold stride forward in the world of software engineering. By fostering a culture of frequent integration, streamlined collaboration, and rapid innovation, this approach accelerates development cycles and enhances code quality. It underscores the significance of continuous integration, automated testing, and efficient development workflows.

This article covered the advantages, disadvantages, and best practices for implementing trunk-based development.

Aviator: Automate your cumbersome processes

There are 4 key components to Aviator:

MergeQueue – an automated queue that manages the merging workflow for your GitHub repository to help protect important branches from broken builds. The Aviator bot uses GitHub Labels to identify Pull Requests (PRs) that are ready to be merged, validates CI checks, processes semantic conflicts, and merges the PRs automatically.
ChangeSets – workflows to synchronize validating and merging multiple PRs within the same repository or multiple repositories. Useful when your team often sees groups of related PRs that need to be merged together, or otherwise treated as a single broader unit of change.
TestDeck – a tool to automatically detect, take action on, and process results from flaky tests in your CI infrastructure.
Stacked PRs CLI – a command line tool that helps developers manage cross-PR dependencies. This tool also automates syncing and merging of stacked PRs. Useful when your team wants to promote a culture of smaller, incremental PRs instead of large changes, or when your workflows involve keeping multiple, dependent PRs in sync.

Try it for free.

The post Embracing trunk-based development: Advantages, disadvantages, and best practices first appeared on Aviator Blog.

The post Embracing trunk-based development: Advantages, disadvantages, and best practices appeared first on Aviator Blog.