Automated BizTalk Deployment

BizTalk Server, otherwise referred to simply as BizTalk, is a middleware product used to connect various systems. For example, you might be using a different system for your HR, your finances, and your CRM system. BizTalk sits in the middle of everything, making sure each tool is able to communicate and work together.

Deployment Framework for BizTalk

The deployment framework for BizTalk, or BTDF, is an Azure DevOps extension that facilitates the deployment and configuration of BizTalk applications. The tasks available in this extension include deployment, undeployment, and installing an MSI. BTDF does not build BizTalk applications, but it does eliminate all manual steps and human intervention in your deployment. The deploy/undeploy tasks in this extension require artifacts built using the BTDF Visual Studio extension. This VS extension can also help increase developer productivity with tools such as binding file management.

Automatic Deployment

Historically, deploying BizTalk solutions has been somewhat of a pain. The Deployment Framework for BizTalk extension for Azure DevOps and Azure DevOps Server will enable automatic deployment of your solution into all the environments in your release pipeline. These automated deployments can be made into a native part of your BizTalk development lifecycle.

To get started, or for more information on the Deployment Framework for BizTalk extensions, contact us here at PRAKTIK today.

Azure DevOps Server 2019 Update 1.1

Update 1.1 for Azure DevOps Server 2019 is a roll up of bug fixes and security patches. This includes any patches put out prior to this update. Three major pain points that have been fixed in this release are Elasticsearch failures, high memory usage and collection sorting.

Collection Sorting

Prior to Update 1, project collections were sorted alphabetically. However, the sorting appeared to be random after the update. This made it difficult for teams with multiple collections to find what they were looking for. Update 1.1 put out a fix for this, bringing back the alphabetical sorting.

High Memory Usage

After installing Update 1, many noticed that Azure DevOps Server appeared to slow down significantly. This affected processes such as the web portal and even simple folder navigation. Those experiencing this problem noticed the slowdown was due to very high memory usage. One user noted that their memory usage was over 90%. For some, this also presented a financial problem: adding memory to cope with this higher usage would come at a cost. Fortunately, Update 1.1 has remedied this issue.

Elasticsearch Failures

Elasticsearch is an open-source, distributed search and analytics engine. It has many use cases, including for application search, enterprise search, and log analytics. Prior to this update, some received an error when setting up Elasticsearch: "User not authorized." Still others experienced indexing and query failures when upgrading from TFS 2018 Update 2 or newer. Update 1.1 resolved both of these issues.

For more information on Azure DevOps Server Update 1.1, or to speak to an expert about troubleshooting or installation, contact us here at PRAKTIK today.

Azure DevOps Services vs. Azure DevOps Server

Azure DevOps Services and Azure DevOps Server – formerly called Visual Studio Team Services and Team Foundation Server, respectively – are two separate but similar development tools. They can help with planning, versioning, and even deploying your code. Azure DevOps Services is a cloud offering. It is scalable, reliable, and globally available. It is also backed by a 99.9% SLA and is monitored around the clock. Azure DevOps Server is the on-premises sibling of Azure DevOps Services. Companies choose this option when they need to keep their data within their own network, or to take advantage of SQL Server reporting services. While both tools offer the same necessary resources, there are a few fundamental differences to consider when deciding which is right for you.

SQL Server Reporting

One difference between the cloud and on-premises versions of Azure DevOps is SQL Server Analysis Services. This data reporting service supplies data models for business reports and applications such as Power BI and Excel. SSAS is installed as an on-premises server instance and supports tabular models at all compatibility levels. At the time of this writing, SQL Server Analysis Services are only available in Azure DevOps Server.


Scope and Scale

Azure DevOps Services scales in two ways: by organization and by project. Organizations have their own unique URL, and they all have one project collection. Each method has scenarios in which they are more successful. For instance, having one organization with many projects is useful when different efforts require different processes. On the other hand, Azure DevOps Server scales in three different ways: by deployments, by project collections, and by projects. For more about the methods of scale and how to plan your organizational structure, see the documentation.


When using Azure DevOps Services, authentication is done over the public internet with Microsoft account credentials or Azure Active Directory credentials. If using Azure AD, you can also require multi-factor authentication or IP address restriction. When using Azure DevOps Server, you connect to an intranet server. You can use Windows Authentication and AD domain credentials for authentication.

These are just a few differences between Azure DevOps Services and Azure DevOps Server. Additional details and examples can be found here.

For more information, or to get started with a migration, contact our team here at PRAKTIK.

GitHub Actions

Earlier this year, GitHub announced that Actions were publicly available. Actions in GitHub are individual tasks that interact with your repository. This interaction can be anything, including integrating with a public API to sending SMS alerts when urgent issues are created. Actions can be combined to create jobs and customize workflow. Furthermore, you can create your own actions, or you can customize actions created and shared by others in the community, like these for Azure.

Types of Actions

There are two types of actions: Docker container actions and JavaScript actions. A Docker container allows you to specify OS versions, dependencies, and tools. Therefore, for actions that require a specific environment configuration, Docker is ideal. JavaScript actions, on the other hand, can run directly on a machine. Using a JavaScript action simplifies the action code and thus executes faster than a Docker container action.

Understanding Differences

Understanding the differences between various tools is key to being efficient and effective in your efforts. GitHub Actions and GitHub Apps, for instance, both provide ways to build automation, but each has qualities that make them efficient in differing scenarios. GitHub Actions provide automation to enable CI and CD and can run directly on a runner machine or in a Docker container. They also don’t require you to deploy code. Conversely, GitHub Apps perform well when persistent data is needed and are best suited to API requests that aren’t time-consuming. Additionally, they run on a server or infrastructure provided by the user.

To get started with GitHub Actions or to speak with an expert, contact us here at PRAKTIK.

Easy SQL and SSIS Deployments with Azure DevOps

If you’ve ever tried to jump into using Git, you know how steep the learning curve is. With terms like “rebase,” “branch,” and “fork,” it can be overwhelming. In fact, this learning curve sometimes dissuades teams from migrating to Azure DevOps or even using Git at all. Git can be extremely powerful, but that power is lost if you simply don’t know how to use it. That’s where our custom deployment tool comes in. This tool takes out the Git learning curve and allows you to take advantage of the power of Git and Azure DevOps with the push of a button.

For instance, let’s say you’re on an IT team that does database deployment. There are 40 DBAs deploying SQL and SSIS package changes into production on demand. Additionally, you have developers that do not combine changes into one release; they simply release into production on their own without any kind of release schedule. Clearly, there needs to be a way to audit what goes into production.

You’ve been tasked with configuring a third-party application for your development team, and you want to do this using SQL. In the past, deployments have been handled via emails between analysts and DBAs.

Now, things have changed. After our tool is installed and customized, all you’ll need to do is upload your SQL scripts to Git using the UI. To do this, select the script you wish to upload, and decide where you want to deploy it.

Then, give it a release description in the text box and click submit. This action opens up Azure DevOps, where you can see the release. 

That’s it! You’ve successfully released your change into the environment of your choosing. You can also enable pre-deployment approvals so that releases don’t move into production unchecked.

This custom deployment tool allows you to take advantage of Git concepts and traceability without having to become an expert. The Azure DevOps Audit Trail is also augmented with copies of every script that ran in every environment. The purpose of Git is to manage a project as it changes over time, and this extension helps you do just that.

To get started, or for a free consultation of our other services, contact us here at PRAKTIK today.

Azure DevOps – Jira Integration

Azure DevOps and Jira are two very popular development tools. If both tools are used by a team or organization, it can be difficult to keep track of what changes are where. This is where TFS4JIRA comes in. TFS4JIRA is a Jira plugin that functions as a migration, integration, and synchronization tool to bridge the gap between Jira and Azure DevOps.

Features of TFS4JIRA

One of the biggest draws for this plugin is the ability to automatically sync changes made to issues and work items between Azure DevOps and Jira. This includes attachments, comments, and changes in summary and labels. It also offers a simple association of Azure DevOps check-ins with Jira issues via a comment or note with the issue key. Once your TFS4JIRA profiles are set up, the plugin will work in the background, checking for new activity at an interval specified by you. TFS4JIRA works regardless of if solutions are deployed on-premises or in the cloud.

This plugin also enables you to migrate Azure DevOps to Jira. There, you can create your sync profile, complete with health checks. For a full list of features and capabilities, see the documentation.

Getting Started

To get started with TFS4JIRA, simply download and install the TFS4JIRA Synchronizer from your Jira instance. For a more seamless experience, however, PRAKTIK can do this for you. We can also customize and extend your implementation to make the integration as seamless as possible so you can get to work. Contact us here at PRAKTIK for a consultation.

Git Branching Strategies

One of the greatest advantages of Git is its branching capability. This capability allows individuals to have a great deal of freedom in how they choose to share and manage their code. However, for teams to collaborate effectively, a consistent branching strategy should be adopted. A solid branching strategy is crucial to the success of decentralized version control. Concepts that may facilitate this success are feature branches, pull request reviews, and keeping a high-quality master branch.

Feature Branches

Work on features and bug fixes should be kept isolated in feature branches. This helps ensure that the master branch always has production-quality code. Branches in Git are cheap and easy to maintain, so even smaller pieces of work should have their own feature branches. In the case of long-lived feature branches, a feature flag can be an effective tool. A feature flag allows for a change to be merged back into master, but keeps the work hidden from users. Once the feature is complete and ready for production, the feature flag is removed and the feature is rolled out.

Pull Request Reviews

A pull request is a method by which contributions to a project are made. A pull request should be submitted for review each time, before a branch is merged into master. When submitted for review, these pull requests should provide enough detail to allow the reviewer to be quickly brought up to speed. It should also include a method by which it can be tested, such as a build. Additionally, the responsibility to review pull requests should be shared across the team for the greatest efficacy. If a pull request does not pass the review process, it should not be merged into master.

Master Branch Guidelines

A master branch should be high-quality and always up-to-date. This is important because branches created from master are then known to stem from a good version of code. A good practice to follow is to set up a branch policy for the master branch. This policy should require a pull request prior to merging code, as well as a successful build to complete a pull request. It should also add reviewers when a pull request is created. These requirements will help ensure quality and consistency in the master branch.

These are just a few things to get you started with your branching strategy adoption. For more information, or if you need help with your branching strategy, please contact us here at PRAKTIK.

Sprint Planning Tools

A sprint is a period of time in which an increment of usable product is created. Before a sprint begins, sprint planning must take place. Sprint planning is the time in which a team determines what can be delivered in the sprint, and how the work will be delivered. This planning can be supported with Agile tools, including the team capacity planning tool, the Taskboard, and the sprint burndown chart.

Team Capacity Planning Tool

This tool allows you to set the total number of hours or days your team has per sprint. You can set individual team member capacity, as well as schedule any days off. When an individual’s capacity is set, the capacity bar for that individual appears. Capacity bars give a graphical representation of the time a team member is able to commit to a sprint. They can also offer information about whether someone is at, under, or over capacity.


The Taskboard functions as a progress board for a sprint’s work items. The board is customizable to fit your needs. During a sprint, tasks should be updated often to yield a smoother burndown chart. Consistently updating a task is a good habit to get into so that the Taskboard is always accurate.

Sprint Burndown Chart

A sprint burndown chart is a tool to collect project data and determine team progress throughout the sprint cycle. It also helps mitigate any risk and identify requirement creep. It helps determine if the team completed the work estimated during the sprint planning meeting. The blue area of the chart shows the work actually completed, as well as any task build up. The ideal trend line is a smooth and steady burndown of work. A sprint burndown chart is very helpful, especially as a way to see the velocity history of a project.

This is just a handful of tools that can be used to help with your sprint planning efforts. For more information, or if you need help with your sprint planning, please contact us here at PRAKTIK.

TFS to Azure DevOps migration

Azure DevOps is the cloud-based sibling of Azure DevOps Server. Simply put, it’s everything you know and love about the on-premises solution with none of the maintenance. With Azure DevOps, you’ll have access to the latest features every three weeks. The features are scalable, reliable, and available wherever you need them. Furthermore, when you choose to make the switch from on-premises to the cloud, you can take your data with you – your work item numbers, Git commit IDs, and much more will remain exactly the same. Are you ready to get started with your migration?

Azure DevOps Data Migration Tool

There are few things more important than having the right tool for a job. The Azure DevOps Data Migration Tool is a precision method to migrate collection databases from Azure DevOps Server to Azure DevOps. The Migration Guide outlines the different phases required to move from Azure DevOps Server to Azure DevOps. These phases include everything from getting started to successfully importing your data.

A visual representation of the phases described in the Migration Guide.

Upgrade Support

One of the most important pre-requisites for this migration is ensuring your database schema version is as close as possible to that of Azure DevOps. This means that if you are currently running a version of Team Foundation Server, you must first upgrade to a supported version of Azure DevOps Server. Migration support for a given version of Azure DevOps Server should last from six to eight months. Therefore, it is imperative to take this support window into account when planning a migration. At the time of this writing, the supported versions are Azure DevOps Server 2019 and Azure DevOps Server 2019.0.1. 

Even with all the tooling and guides available, migration can be a confusing process. Why not let PRAKTIK handle it for you? We will create a migration plan, execute a dry-run, and, of course, carry out the live migration. We will also provide targeted user training to cover standard use cases of the new platform. Contact our team of experts to begin planning your migration today.

New Merge Types in Azure Repos

Azure Repos is the portion of Azure DevOps and Azure DevOps Server that houses repositories. Following recent updates to Azure DevOps, two of the most community-requested Git features are now supported: rebase with pull request and semi-linear merging.

Rebase with Pull Request

A rebase allows the integration of a pull request branch into the master branch. That is, the contents of each commit on the pull request branch are brought over to the master branch individually. The advantage of this is that it works even when you’re not ahead of the master branch, such as when someone else has pushed changes to it. The rebase with pull request operation results in a linear history, like in a fast-forward merge. However, it allows for greater flexibility when bringing in new changes. The following gif from the Azure DevOps Blog gives a concrete visualization of this process.

Semi-Linear Merging

A semi-linear merge is also known as “rebase and merge.” With this type of merge, a merge commit is created but merging is only allowed if the branch has been rebased. The advantage of this is a history that reads linearly, with the addition of merge commits.

The following graphic from GitHub gives a way to visualize the difference between a merge, rebase and merge linearly, and rebase and merge semi-linearly.

Both rebase and semi-linear merging are available in the Complete Pull Request dialog in Azure DevOps. Furthermore, the policy administration page has been updated to allow administrators to control which strategies are allowed.

If you need any help with GIT branching, contact our team at PRAKTIK and we can help you decide on the best branching strategy.