Today in this article, we will see how to Identify Azure Pipeline Id For Devops In ADO.

We will see 2 simple approaches to find the pipeline ID.

In the first approach, we will use the AZ command to get details about the pipeline, and 2nd is a more kind of manual approach to get the Ids.

Today in this article, we will cover below aspects,

Approach 1- Using AZ command to get the pipeline ID and other information

Command

az pipelines show --organization <your org name> --project <project name> --name <name>

Example

az pipelines show --organization https://dev.azure.com/jan2022-thecodebuzz --project globalexceptionhandler --name globalexceptionhandler

As highlighted below, the response from the API shows the Id returned as 5

While using the above command you might need to log in again to confirm the connections setting ,

Approach 2- Using ADO Pipeline Edit command to pipeline ID and other information

You can also use the ADO Pipeline Edit command to get pipeline ID and other information manually as shown below,

Once you click on EDIT, you can find the pipeline ID with the URL below,

References:

• Create HTTP with NGINX on Linux in Azure Virtual Machine

Do you have any comments or ideas or any better suggestions to share?

Please sound off your comments below.

Happy Coding !!

Please bookmark this page and share it with your friends. Please Subscribe to the blog to receive notifications on freshly published (2025) best practices and guidelines for software design and development.

The post Identify Azure Pipeline Id For Devops In ADO first appeared on TheCodeBuzz.

Today in this article, we will see how to use API for Automating Azure DevOps Build Pipelines using Run Pipeline API.

We will see an example of how to trigger Azure Pipelines build via API. AS we learned in the last article we have below two approaches to call REST API for Build pipeline,

• Build -Queue API
• Runs – Run Pipeline API

We already looked at the Build queue approach in the previous article.

Today in this article, we will cover below aspects,

For more details please see below article,

• API for automating Azure DevOps Build Pipelines – Part 1

Both approaches have similar settings/configuration steps and hence they are easy to configure.

Trigger a build using – Run Pipeline

Build pipeline

POST https://dev.azure.com/{organization}/{project}/_apis/pipelines/{pipelineId}/runs?api-version=6.0-preview.1

Build pipeline With optional parameters

POST API

POST POST https://dev.azure.com/{organization}/{project}/_apis/pipelines/{pipelineId}/runs?pipelineVersion={pipelineVersion}&api-version=6.0-preview.1

Input Parameters

In the above Post request below are the input parameters,

• organization – The name of the Azure DevOps organization.

• project – Project ID or project name

• api version – Version of the API to use.

Request Body

• definition – The build number/name of the build.

Below is our sample repository,

https://dev.azure.com/jan2022-thecodebuzz/globalexceptionhandler/_build

Configuration and security

Let’s now configure the API to be invoked securely.

Step1- Click on the User settings and set up the personal access token.

Define a name for this token and authorize the scope of access with this token. You can choose this token access for Build pipeline trigger or release pipeline trigger etc.

Finally below is our URL and input request object defined,

URL

https://dev.azure.com/jan2022-thecodebuzz/globalexceptionhandler/_apis/pipelines/5/runs?api-version=6.0-preview.1

Let’s now use Postman to execute the API. Please set up the Basic authentication in the Postman by setting up the Token name as UserName and Password as a personal access token.

Request Object for Build Pipeline API

Below is my request body,

{
    "resources": {
        "repositories": {
            "self": {
                "refName": "refs/heads/master"
            }
        }
    }
}

Response from Build Pipeline API

Below is a sample response,

Once you execute the POST API, please check your pipeline. You shall see it is executed and triggered for a build successfully,

References:

• API for automating Azure DevOps Build Pipelines – Part 1

• Create HTTP with NGINX on Linux in Azure Virtual Machine

Do you have any comments or ideas or any better suggestions to share?

Please sound off your comments below.

Happy Coding !!

The post Automating Azure DevOps Build Pipelines using Run Pipeline API first appeared on TheCodeBuzz.

Today in this article we shall learn the differences between Self Contained Vs Framework Dependent Deployment i,e, SCD and FDD deployment methodologies. These deployment techniques are generic and can be used for Console or ASP.NET API or WebAPI or any MVC project.

Today we will cover below aspects in the article,

Applications created using the .NET framework can be published in two different modes, and the mode affects how a user runs your app.

When installing the application to the new environment, if the target machine has the required .NET version already installed then the application built using .NET should work without any issue.

If the required .NET core SDK/runtime is not installed then one can follow any of the below approaches discussed. An approach using Self-content deployment doesn’t require a .NET Core SDK/Runtime to be installed on the target machines.

Let’s see both the approaches in detail,

FDD- Build Application as FDD- Framework-dependent deployment

If you are building an application using Framework dependent deployment (FDD) approach, then it is expected that the target server or environment has the .NET Core SDK and runtime installed.

Publishing an app as FDD produces a cross-platform binary as a DLL file, and a platform-specific executable.

Deployable mainly consist of below,

• Application-specific DLLs or EXE
• Dependencies like NUGET or Third party references
• Resource files if any

Example of Framework-dependent deployment

Below FDD deployment has produced below binaries,

As shown above, my deployable consist of Dlls like ExternalDLL1, ExternalDLL2, and Nuget packages like Newtonsoft, etc

All the system DLLs and supported Runtime/SDK will be used from the below folder on the target machine,

.NET Runtime

C:\program files\dotnet\shared\{runtime-type}\{version}\
C:\program files\dotnet\host\

Example: runtime framework DLLs like hostfxr.dll can be found in the below-shared location depending on the target .NET version used,

Advantages of Framework-dependent deployment

There are below advantages of using this approach,

• Small deployment – With this option, you create your deployable consisting of the actual app and its dependencies i.e mainly these part libraries or NuGet package used by your application.
• Leverage the latest patched runtime.

Disadvantages of Framework-dependent deployment

There are below disadvantages of using this approach,

• .NET Core installation needed – Prior installation of the required .NET Core runtime is needed.
• .NET version may change the behavior of the app – With this option, it is possible that the application will use the latest available version on the target machine which could affect application behavior to some extent.

Example :

Your application target and uses the 5.0.0 version then let’s say your machine gets patched with the 5.0.1 version. In such cases, your application will start using the 5.0.1 version, since it’s the highest patch and the runtime available for the given major version of 5.0.x.

The above behavior can be changed by using a custom configuration like app roll forward settings.

SCD- Build Application as Self-contained Deployment

If you are building an application using an approach, then you are making your application deployable is self-content, and can run on its own.

This can be achieved by building your application using the below build command,

Self-contained Deployment For Linux

Sample command for self Content Deployment for Linux

dotnet publish -r linux-x64 --self-contained true -c release

Self-contained Deployment For Windows10

Sample command for self Content Deployment

dotnet publish -r win10-x64 --self-contained true -c release

OR

For Windows Server

dotnet publish -r win-x64 --self-contained true -c release

Deployable mainly consist of below,

• Application-specific DLLs or EXE
• Dependencies like NUGET or Third party references
• Resource files if any
• System DLLs
• Runtime/SDK

The user of your app isn’t required to download and install it. NET, as your application, will now have everything to run as self-content.

Self-contained Deployable Example

Below SCD deployment has produced below binaries,

Size of my application deployable now increased to 64 MB due to all application,System DLLS and Runtime/SDK are packaged together.

Advantages of Self-contained Deployable Example

With this approach, you achieve the below advantages,

• The app doesn’t required to download and install. NET.
• Application is isolated from other .NET apps
• The application doesnt use a locally installed shared runtime even if available
• You are able to control which target version you want to use.

Disadvantages of Self-contained Deployable Example

• The large size of deployment -The app includes the .NET runtime and all the dependencies making your deployable size tune to the maximum.
• .NET version compatibility – For any specific framework version-related chnages including major, minor versions require new deployment.

References:

• Create a Self-contained package for Build and Deployment

Do you have any comments or ideas or any better suggestions to share?

Please sound off your comments below.

Happy Coding !!

Please bookmark this page and share it with your friends. Please Subscribe to the blog to receive notifications on freshly published (2025) best practices and guidelines for software design and development.

The post Self Contained Vs Framework Dependent Deployment -Guidelines first appeared on TheCodeBuzz.

Most of us understand the importance of code quality. Good coding practices are language agnostics and help any organization to deliver clean, highly reliable, secure, and maintainable code. Today in this article, we shall see how to manage the Code Quality of .NET with SonarQube.

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand”  -Martin Fowler

Software maintenance is like a big fat elephant and often eats away a big chunk of project budget allocation. Re-engineering and refactoring of buggy code cost organization time, cost, and quality. These small-looking coding issues become bigger problems in the future and potentially affect the complete architecture and design of your application.

“Code is maintained more often than it is written”

Today in this article, we will cover below aspects,

Today in this article we shall see how to use the Sonar Lint IDE extension in Visual Studio 2017(or VS2019)

SonarLint is an IDE extension that helps to detect and fix code quality issues as you type the code in IDE.

SonarLint Visual Studio extension combines together all best of the linting process and supports multiple analyzers and multiple languages.

• C# (.NET , .NET Core, .NET Standards) – Roslyn analyzer

• VB.NET- Roslyn analyzer

• JavaScript- SonarJS analyzer

• C/C++ – SonarCFamily

Support for Typescript or Python language is supported through another SonarLint plugin that works on Visual Studio Code IDE. Please see more details on the below link,

• Continuous Code Quality of Angular, React or Vue.js applications using Sonar

Getting started – Code Quality of .NET with SonarQube

Prerequisites:

* Visual Studio 2015 or 2017 or 2019

* Install SonarLint extension

From Menu->Extension->Manage Extension, please search with the keyword “Sonar” as below. Here I am installing this extension for VS2019.

Note-The first-time installation requires you to restart the Visual Studio to complete the installation.

After successful installation of the extension, IDE will start analyzing code and shall start reporting the issue as shown below,

As you type your code you shall be able to see the best recommendation from SonarLint based on configured rules.

Sonar – Connected Mode configuration

SonarQube scan can be configured as part build and deploy process within the CICD pipeline. SonarQube provides the overall health of the portfolio within the organization with nice dashboards detailing the overall health of the code.

Sonar Server

SonarLint if used with the SonarQube server streamlines the code analysis process by using a uniform rule set across the organization and avoids any ambiguity of issues reported on server vs developers Desktop/IDE. So far above we used the default ruleset which comes with plugin installation now we shall see how to use the connected mode of the sonar server.

Connected mode configuration is a simple 1-2 step process. Below we shall try connecting the application with a quality profile of the server.

• Click on Team Explorer in Visual Studio and connect to SonarQube as shown below,

• Provide Server URL and Password or Token to connect with sonar server from IDE,

After successful authentication, please select your organization.

Your application will be connected.

Establish the Sonar Server connection for the first time. Please click on “Bind” as shown below,

After successful binding, Quality profiles from Sonar Server will be downloaded locally in your projects which includes ruleset file and creation of .sonarlint folder as shown below,

• Sonar rule set file will be created within project folder (.csproj)

• Folder ‘.sonarlint‘ will be created with ruleset file and configuration file as below,

That’s all! Once the project gets connected with the server, Your project will work in connected mode using the same Quality profiles as of Sonar Server.

You will be able to see the same coding issues in IDE and in Pipeline and analyze your code against centralized configured rules.

Happy coding !!

Do you have any comments or ideas or any better suggestions to share?

Please sound off your comments below.

Happy Coding !!

Other References :

• Continuous Code Quality using NDepend

• Continuous Code Quality of Angular, React or Vue.js applications using Sonar

Summary :

Today we learned about SonarLint extension set up and configuration for Visual Studio IDE. Good coding practices are language agnostics and help the organization to deliver clean, reliable, secure, and maintainable code. Buggy code slipping through cracks has the potential to cost a company an entire business.

Organizations can address these problems by following best practices of software development like continuous code quality and continuous code review processes.

Please bookmark this page and share it with your friends. Please Subscribe to the blog to receive notifications on freshly published (2025) best practices and guidelines for software design and development.

The post Continuous Code Quality of .NET with SonarQube first appeared on TheCodeBuzz.

Trunk-based development is a prominent source code Branching Strategy that follows a set of defined principles and best practices to perform code development on a branch called ‘Trunk’ or ‘Master’ in a collaborative way.

A source-control branching model, where developers collaborate on code in a single branch called ‘trunk’ *, resist any pressure to create other long-lived development branches by employing documented techniques. They therefore avoid merge hell, do not break the build, and live happily ever after.

_ Source https://trunkbaseddevelopment.com/

We will cover the below aspects in the article,

Trunk-based development is getting huge traction recently.

These recognitions are mainly due to the realization of the fact after a decade of experience and learning on the various issue of traditional VCS (Version Control system) like Merge hell, Testing failure followed by a delay in delivering a feature and then delay in testing and acceptance, etc.

Origin and Merge Hell

The code integration phase is still an important phase even in modern code development methodologies. Generally, once a feature development is over as we know of integration of the code from different developers.

This merging sometimes also depends on multiple aspects like environment, the feature is integrated, the client-specific requirement being addressed, etc.

This merging is always challenging, as it involves a huge code base merge developed over a period of time.

The integration phase is always critical to delivery.

If any issue arising at that time could affect directly the delivery of the product.

The issue could become worse with an approach of having multiple parallel repositories in a different environment dealing with code movement from one environment to another environment.

Finally, These problems are always man-made. The good thing is these problems are solvable with best practices.

There are many mechanisms for practicing lean-agile methodologies.

Trunk-based development is slowly becoming one of the methods helping with a few common issues on code merge thereby targeting speed to the market initiative.

TBD actually complements your already established lean-agile practices and the team can get value from its usage.

Trunk Based development-based branching strategies help in practicing frequent releases and delivery of features and helping to achieve speed to the market initiative.

Trunk Based Development’s main advantage is that it keeps feature/code near to the production readiness right from the kickstart of a project.

It’s important to understand that when a feature or code is near to the release Or production readiness continuously, the team gets a lot of flexibility on revisiting the features, introducing a change in a feature or updating an implementation, or making changes to code as per the requirements.

Also, the team can revisit on design and architecture of applications if needed.

The team keeps on integrating code even if the feature is not complete. The idea here is simple, issues are easy to fix when they are small.

Trunk-based development encourages small features to be integrated in an incremental way.

A known limitation in the world of waterfall dealing with legacy source code, you will typically observe one continuous build that culminates in one deployment for a bunch of features spanning over a period of time.

Which most time produces multiple issues like merge hell and bugs etc.

Is it feasible to follow the Trunk/Master Approach?

The feasibility of following the trunk-based development could be a question for most of us.

The simple answer is ‘absolutely’ it is feasible.

There are multiple benefits of using the Trunk approach as explained in the “Benefits” section below.

Feature Toggle – Inevitable

There are multiple supportive techniques useful for following Trunk based development.

The use of Feature toggles is inevitable.

Feature toggles are dependable companions of trunk development and help to achieve the Trunk approach properly.

Trunk-based development can regulate the software development process within your sprint or iteration cycle.  

Teams develop a cadence for a release-ready feature implementation which is integrated together with feature flags.

Benefits of Trunk-Based Development

• Small incremental Feature development gives greater visibility of features being developed.

• Compliment the CI-CD process with Continuous Integration and continuous deployment of code.

• Small Feature development can be aligned with lean Agile methodologies improving the velocity of the team overall.

• Code on Master/Trunk is always ready to be released due to only one Trunk.

• Reduces the cost of manual code merge (usually done in the form of the integration process of the codebase).

• It enables the team’s ability to release new features more frequently.

• Trunk methodologies with a combination of practices improve the quality of deliverables.

• Shift-left enablement.

• Cross-team collaboration with XP practices.

• Eliminates heavy code merges.

Best Practices of Trunk-Based Development

Develop the Trunk/Master

• That means one and only Master or Trunk should be used for all development.
• This is different from Git Flow where actual development happens on dedicated branch-like DEV then Test etc.
• One should always use Feature Branches for small feature development.
• Small Feature Branch should not last for more than 1-2-3 days.

Feature Branch life span a few days(1-3 days)

• Developers should develop a practice of not keeping the code to themselves.
• The code should be merged with Master within a few days, typically 1-3 days.
• Code merge should be done for what you own that day with the precondition of a successful build, and test cases passing.
• Code merge can be done even if the feature is not complete. Make sure build and test cases are passing.

Create Feature branches from the Master/Trunk

Example

• Ex, If using Git as VCS then origin/master (remote) should be used for creating a Feature branch.
• The idea here is every new development should progress using the latest available code from Master/Trunk.

Feature Branches can be Aligned with the small feature and hence user stories or task

• New Feature branches can be created for small development and can be aligned with user stories or tasks.
• If aligned with a user story or task, please make sure the Feature branch code doesn’t last long beyond 2-3 days.
• The idea here is to merge and deploy small features in logical chunks and as early as possible usually within 1-3 days.

Clean merges to Trunk/Master

• The small feature developed should be validated, and reviewed within the Feature branch itself right before the merging to Master/Trunk.
• Always sync your changes from the source control.
• Feature branch code should be reviewed before the merge to the Master/Trunk.
• Clean merges here means code that is in a Green state i.e passes build, unit test, etc.
• Do only clean merges to Trunk which are validated and reviewed

Don’t commit to Master/Trunk directly

• It’s recommended not to commit directly to the Master/Trunk branch instead one should create a Feature branch (short 1-3 days).

• It’s recommended to create a feature branch for every merge.

• Smaller teams sometimes tend to check directly to the Master which is okay for a team of 1 or 2 (if code review is followed strictly.)

Merge should be from a Feature branch to the Master/Trunk

• Merge should be unidirectional that is from a Feature branch to Master/Trunk.

• Merge from the Release branch to the Master branch can be avoided.

• Intermediate merges to master (Trunk) are not allowed.

Every merge should be production-ready

• Do a clean merge with known and agreed functionalities including limitations if any.
• Do clean merges even if the feature is not completed fully.

Merges to Trunk/Master

• Merges between one Feature branch to another Feature branch must be avoided.

• The best practice is to follow the uni-directional merge that is merge of Feature Branch to Master/Trunk should be used.

Feature branch>>>> Master/Trunk>>>>>>Release Branch

Keep Trunk/Master Green

The definition of green can be defined as below,

• Green for the compile and build.

• Green for the Feature being developed. It should work with known and agreed functionality.

• Green for the acceptable Test including unit tests or integration test cases.

• If the build fails, revert your changes back to the previous best state of code. One should create a new Feature branch for fixing build issues.

Release branch to Master branch merge should be avoided

• Merge from the release Branch to the master should be avoided. There are rare exceptions though (which I will talk about in future articles).

References

• Cherry Pick in Gi for Trunk-based Development

Summary

Trunk-based development is a prominent source code Branching Strategy that follows a set of defined principles and best practices to perform code development on a single branch called ‘Trunk’ or ‘Master’ in a collaborative way thereby minimizing the merge/integration pain.

It complements continuous integration and continuous delivery by keeping the code “ready to release” state and developing a cadence of merging small changes in an incremental way.

Please bookmark this page and share it with your friends. Please Subscribe to the blog to receive notifications on freshly published (2025) best practices and guidelines for software design and development.

The post Git Branching Best Practices – Trunk-Based Development first appeared on TheCodeBuzz.