Integrate Microsoft Teams with Azure DevOps

Microsoft Teams is a tool for team collaboration in Office 365. It goes far beyond a simple chat or video call client. This tool also helps enable teamwork with application integration and file sharing. This has become especially important in today’s world with more and more people looking for ways to effectively work from home.

When Azure DevOps is integrated with Microsoft Teams, you have a comprehensive collaboration experience across the full development lifecycle. Team members will be able to stay on top of projects with an array of notifications on actions such as pull requests and commits.

Getting Started

To integrate your Azure DevOps with Microsoft Teams, you’ll need an Office 365 account. If you don’t have one, you can sign up for a free trial here. Additionally, only Azure DevOps organizations in the same AAD tenant can be used to integrate with your Teams account. You will also need to have a team created within Microsoft Teams. For a step-by-step walkthrough, check out this blog.

 

Integration

To get started with the integration, you’ll need to add a connector to your team channel. A connector allows your team to get content and updates from different services, including Twitter, GitHub, and, of course, Azure DevOps. After adding the connector, you’ll be prompted to configure it by selecting your organization, team, and project.

After your connector is configured, you can further customize how your Microsoft Teams channel shows Azure DevOps data. For example, you’re able to display your Kanban Board or even monitor your Azure Pipeline with a bot. This means you’ll be able to do more work from one single place instead of navigating through a bunch of different apps.

For more information, or to get started with your own Teams-Azure DevOps integration, contact us at PRAKTIK today.


Automated Oracle Integration Deployment with Azure DevOps

Oracle Integration is a service that allows you to integrate your cloud and on-premises applications, automate processes, and develop visual applications. This service is built to be integrated with other tools. This integration can be done using pre-built adapters, or by leveraging its API. Using this integration capability, PRAKTIK has developed a tool to help you export your data from the Oracle Integration Cloud to Azure DevOps to take advantage of source control.

The Flow

This tool uses actions you’re already familiar with. You’ll start by exporting your code from the Development environment in the Oracle Cloud to an Azure Repo to be committed and versioned. Then, you’ll get a notification for approval. After it is approved, the code is imported into your next environment within the Oracle Cloud. Before each import into a new environment, an approval notification will be sent. Finally, it is imported into your Production environment back in Oracle where it will run.

 

How It Works

This tool leverages the Oracle Cloud Infrastructure API to connect the Oracle Cloud to Azure DevOps. To use the tool, a developer will simply initiate a release. The data from Oracle Cloud is then pushed using Git to an environment in Azure DevOps as an IAR file. There, you can see the history of your application and compare changes more readily.

In Azure DevOps, your pipeline is fully customizable to your needs. You can even have an environment to roll back any unwanted changes.

Getting Started

The only pieces of information you need to begin are the URL to your Oracle Cloud and the login information for it. After that, the tool does the rest. For more information or to get started today, contact us here at PRAKTIK.


Azure Pipelines: YAML or Classic UI?

When creating an Azure Pipeline, you’re given the option to use YAML or to use the classic editor. YAML is a relatively new option, but should you choose it simply because its new? Which experience is truly the best choice for you?

YAML

YAML is a data serialization language that is designed to be human-friendly. That is, it presents data in such a way that people can read and understand it. YAML also works well with other programming languages. Full documentation on YAML can be found on its official site.

When using this option, you’ll define your CI/CD strategy and your Pipeline definition as code. Because the YAML file is just a text file, you’re able to take advantage of things like pull requests, history, and code reviews, just as you would with the rest of your application. Additionally, the fact that it is a text file makes it much easier to share between team members for collaboration. There is also an Azure Pipelines extension for VS Code. This extension can help you out by adding syntax highlighting and autocompletion for your YAML file.

Classic UI

The Classic UI is the graphic user interface we all know. Using this option, you’ll create and configure your build and release pipelines in the Azure DevOps web portal. Your build pipeline will create an artifact that can be used to run tasks such as deployment to staging or production environments.

The Classic UI is familiar, and less intimidating at first glance than YAML. It doesn’t require you to write, test, or debug a text file. There is no domain-specific language, which lessens the learning curve, especially for those not coming from a development background. The UI is being deprecated, but you do have the ability to convert to YAML.

Features

Another factor that should be considered when deciding between YAML and the Classic UI is the features that are available with each method. For instance, the Classic editor does not support container jobs, but the YAML editor does. Similarly, the Classic editor supports gates, but the YAML editor does not. For a full list of pipeline feature availability, see the Docs.

To get started, or for more information about Azure Pipelines, contact our experts here at PRAKTIK today.


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.

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.