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.

Authentication

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.

Taskboard

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.


Azure DevOps Server 2019

Following the release of Azure DevOps last year, Microsoft has also put out Azure DevOps Server 2019. Azure DevOps Server 2019 is the on-premises sibling of Azure DevOps and features a similar experience. This tool brings in an improved navigation experience, changed licensing, as well as additional functionality.

Navigation

The navigation experience in Azure DevOps Server 2019 is the same navigation found in its cloud-based counterpart, Azure DevOps. This experience is more modern than that found in Team Foundation Server. Additionally, the similarity between the on-prem and cloud products allows for a more seamless transition when moving between the two products.

This improved navigation brings new features as well. For instance, the Backlogs hub has been split into three separate hubs: Backlogs, Boards, and Sprints. The backlogs for a project are in the Backlogs hub. The Boards hub holds the Kanban Boards for a project. Finally, sprint planning features are in the Sprints hub. This navigation was implemented as a result of user feedback, and will help users get work done more effectively.

Licensing

In the past, TFS users needed to purchase an Artifacts extension to use Artifacts. With Azure DevOps Server 2019, however, the Basic License includes Artifacts. Similarly, Azure DevOps Server 2019 users do not have to purchase Release Management Deployment Pipelines; they are now included.

Additional Features

Azure DevOps Server 2019 comes chock-full of new features. One of the most exciting new features is the Pipeline view. This view gives the user a way to visualize the environments and understand their progress and status. It also allows the user to drill into the status and navigate through the logs.

Other sought-after features include YAML build configurations, the ability to ignore a release gate for a deployment, and the ability to fix broken Wiki links when moving pages. For a full discussion of all the new features, please visit the Azure DevOps Server 2019 documentation.

To learn more or to begin your transition to Azure DevOps Server 2019, contact our team today.


Azure DevOps vs. Team Foundation Server

Many are wondering how the new Azure DevOps differs from the latest update of Team Foundation Server 2018. TFS will follow Azure DevOps and be renamed in the 2019 version. It will be called Azure DevOps Server. This product's features will be delivered following the same three-month cadence used in TFS. Until then, here are a few differences to expect between the two products.

Navigation and Modularity

The most obvious difference between the cloud product and the on-premises product is the navigation. Azure DevOps is broken down into five modular pillars: Azure Boards, Azure Pipelines, Azure Repos, Azure Test Plans, and Azure Artifacts. These pillars are designed to be used together, or separately in conjunction with other ALM products. TFS will retain the original navigation until the next update. There is no set date for that release at the time of this publication.

YAML Builds

Another difference between the two products is the ability to configure YAML build pipelines using the new wizard. Once a repository is selected for the build, a YAML pipeline will automatically be created. Otherwise, Azure Pipelines will analyze the build automatically. It will then suggest a YAML template best suited for your build. To use this feature, you must have the preview feature enabled. This feature will be available in Azure DevOps Server 2019.

The cloud product also offers ten parallel jobs and unlimited CI/CD minutes for open source projects. This is currently only available for open source projects running in Azure Pipelines. There are also dozens of additional features that have not yet made it to the on-premises product. These features include being able to change the target branch of a pull request in Git, code coverage in the .NET Core task, the ability to store artifacts using Universal Packages, and so much more.

You can view current and planned features for both Azure DevOps and Azure DevOps Server by navigating to the Azure DevOps Features Timeline.