How to Get Azure DevOps Notifications in Microsoft Teams

With an increasing number of people working from home, it’s more important than ever to be able to collaborate effectively with team members. One way to do this is by using Microsoft Teams. In this post, we will discuss how to get Azure DevOps Services notifications directly to your Teams account.

Getting Started

Before beginning, there are a few prerequisites. Firstly, you must have a Microsoft 365 account. It’s also important to remember that only Azure DevOps organizations within the same AAD tenant can be used to integrate with your Teams account. Next, you’ll need to join or create a team within Microsoft Teams. The people on this smaller team could be your other team members, or other people you’re collaborating with.

The Integration

Now, you’re ready to begin the integration of Azure DevOps with Microsoft Teams. From your team page, select Connectors from the ellipses menu on the right. There, you’ll find a list of connectors available for your team. Select the Azure DevOps connector and click Add. Finally, fill in the requested information to configure your connector and save. With Azure DevOps configured, you’ll begin receiving notifications in your Teams channel.

 

At any point, you can edit the connector for a more personal notification. For instance, here is a sample build failure notification setup.

 

Other Capabilities

The integration experience doesn’t have to stop with notifications. You can also bring your Kanban board, Dashboard, or even your Pipelines into Microsoft Teams. For more information, or help getting started, contact our team of experts at PRAKTIK today.


Make Your Builds and Releases Faster in Azure DevOps

Are your Azure DevOps builds and releases taking forever to run? A lot of things have to go on behind the scenes for a successful deployment. For example, hardware must be allocated for your deployment. If you’re using a public pool of servers, or even a pool of your own, this can take some time. Additionally, build and release pipelines may not be as streamlined as they could be, therefore making everything take just a bit longer. In today’s world, time is precious. Let PRAKTIK Group make your builds and releases faster to give you some time back.

PRAKTIK’s Optimization Service

PRAKTIK is offering this optimization service is offered to our managed services customers. It follows a two-pronged approach. First, we will utilize optimized build machines that take advantage of data caches and RAM disks. This can be done using our infrastructure or your own. No matter which infrastructure you choose, our team will make sure it is refined for your specific use case.

Next, our team of experts will optimize your deployment process. To do this, we will implement a modern branching strategy and eliminate unnecessary artifacts from the build process. Furthermore, we will reduce the number of build and release pipelines required to build your application. All of this can dramatically reduce the time you spend waiting, which means more time available for testing and perfecting your application.

Getting Started

Getting started with our optimization service is as simple as sending an email or picking up the phone. Simply contact us, and our team will provide you with the expert service you need.


How to Move Data Between Azure DevOps Instances

When it comes time to transfer data between Azure DevOps instances, it is important to understand the benefits and limitations of each type of transfer. Data can be moved on an instance level and a project level within Azure DevOps. It can also be moved from Azure DevOps Server on-premises to Azure DevOps Services in the cloud. In this post, we will discuss each type of transfer, as well as scenarios in which each may be appropriate.

Instance Level Transfer Within Azure DevOps Services

In this type of transfer, ownership of data is moved between organizations from one Azure DevOps cloud instance to another. We might also see this during a subscription ownership transfer, or when moving Azure DevOps users from one Active Directory domain to another. This type of transfer is quite simple and doesn’t require major changes. The move can be completed in less than an hour and will require a minimum of two days of planning and preparation.

 

Lift-and-shift On-Premise Collection to Azure DevOps Services

This is a slightly more complicated data transfer. Here, data is moved from an on-premises collection to a cloud instance. It is a lift-and-shift operation, but there are some limitations. For example, rarely-used work item template elements like state transition rules may not be migrated. Furthermore, you may decide to make minor changes before the lift, such as refactoring your application in order to make it work more effectively in the cloud. This type of move is executed over a weekend to minimize downtime and will need between one and three weeks for planning, preparation, and dry run. The time required depends on the size of the collection, the level of customization, and the current on-prem version.

 

Migrate Project Data Between Azure DevOps Instances

This is the most effort-intensive data transfer. This might be used during a company split, reorganization, or acquisition in which Azure DevOps instances need to be divided or consolidated. Lift-and-shift is not a viable option here, as we cannot simply move a copy of the data as it is. Work item IDs will change during the migration. In addition, pull requests and history of Pipelines and Releases cannot be transferred. Similarly, TFVC Source Control history can only be migrated to a Git repository. This type of move is executed over a weekend to minimize downtime and it will need between two and six weeks for planning, preparation, and dry run. The time required depends on the amount of data to be transferred and the level of customization of the Azure DevOps Instance.

Need some help with your transfer? Not sure where to start? Contact our team of experts today.


Keep Your Data Safe with PRAKTIK

Adobe. Equifax. Marriott. These are major, global, well-known companies. What do they all have in common? They have all experienced major data privacy breaches that have left sensitive customer data exposed. These data breaches cost these companies millions of dollars to rectify: Adobe paid a $1 million settlement, Marriot faced a $124 million fine, and Equifax paid an over $650 million settlement.

As important as data security is to the customer, it is even more important for companies that store this sensitive information. One of the biggest questions that comes with using the cloud is, “Is it secure?” In response, cloud providers are as transparent as possible with their security and compliance portfolios. However, this still means that anyone transmitting or storing customer data must be up to date with regional regulations.

Globally, there are varying data residency and privacy regulations. Data privacy refers to a specific kind of privacy regarding personal data. Data residency regulations pertain to where this private data and metadata can be stored in the world, as well as how the data can travel across geographies. There are also different agencies and laws that enforce these regulations, from the European Union’s General Data Protection Agency (GDPR) to California’s Consumer Privacy Act (CCPA).

This feels a little overwhelming, right? Of course you want to protect your customer’s data, and you want to do it the right way. Luckily, PRAKTIK can do this for you. We are up-to-date on global data residency and privacy regulations affecting Azure DevOps so you don’t have to worry about it. Do you deploy to TEST and UAT environments that have customer data? Do you need to move your Azure DevOps instance across geographies? No problem – we can help, and make sure you remain compliant with data privacy regulations.

Want to learn more or get started? Contact our team of experts today for a consultation.

 

 

 


Migrate to Azure DevOps Services from Azure DevOps Server or TFS

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.

Azure DevOps Migration Process

With PRAKTIK in charge, the migration process takes place across a 2 to 6 week period. We will clone the on-premises instance, which allows us to work on the upgrade without any impact for your teams. We will then perform a dry-run migration so that you can run any tests and validate the migrated instance. The live migration will occur on a weekend, which means minimal downtime. We will also provide targeted user training to cover standard use cases of the new platform. Furthermore, we will work directly with Microsoft to resolve any issues that may arise with the migration.

Upgrade Support

One of the most important prerequisites for this migration is ensuring your database schema version is as close as possible to that of Azure DevOps. Therefore, if you are currently running a version of Team Foundation Server, you must first be upgraded to a supported version of Azure DevOps Server. PRAKTIK will take care of this for you, handling on-premises version upgrades from TFS 2005 and up.

Contact our team of experts to begin planning your migration today.


Cut costs with Azure DevOps License Management

An Azure DevOps license is an important tool in your developer’s toolbox. In fact, in some cases, it is the toolbox. To make sure your developers have this tool, they’ll need a Visual Studio Subscription or an Azure DevOps license. To ensure you’re not overpaying and that your developers are equipped to do their best work, PRAKTIK is offering an Azure DevOps License Management service.

Are you Overpaying?

Oftentimes, companies end up overpaying for their developer tools. This can stem from a variety of factors. Maybe paid users have left the company, but their subscription is still active and assigned to them. It is also possible some users have a higher license subscription than is needed, or they have unnecessary paid features. Or, maybe some users have licenses for each individual instance of Azure DevOps, as opposed to one license across the organization. For companies with hundreds of developers, any one of these factors can lead to spending thousands of dollars a month more than necessary.

Benefits of License Management

PRAKTIK can prevent these factors from affecting you by reviewing and updating the Azure DevOps licensing across your organization on a monthly basis. This can bring about major cost savings and cost avoidance for your company – up to 25%. With License Management, you will be able to identify actual software usage. This allows for the elimination of unused software and consolidation of software licenses. Better visibility into your license usage means you only buy what you need, rather than having too many licenses instead of repurposing existing unused licenses. For instance, in the below screenshot, there is a subscription that hasn’t been accessed since 2018. This is a perfect candidate for redistribution or deprovisioning.

Better visibility into software usage also means gaining better license coordination. Any license transfer, acquisition, or disposal becomes easy and efficient. You’re also ensuring your company doesn’t violate compliance terms. Furthermore, this insight into usage will allow for a more accurate IT budget moving forward.

For more information about Azure DevOps License Management, or to speak to an expert, contact us at PRAKTIK today.

 

 


Separation of Duties in Azure DevOps

DevOps is the union of people, process, and products to enable continuous delivery of value to our end users. One of the cornerstones of this concept is breaking down the walls between development and operations teams. This helps enable the teams to work together more efficiently to deliver value. However, this doesn’t mean that there is no separation of duties within DevOps. In fact, there are several scenarios in which this separation is vital. This can be a tricky balance to strike. Luckily, PRAKTIK can act as a third party to manage your Azure DevOps and ensure this separation of duties is maintained.

Development and Testing

On a DevOps team, both development and operations must work together to meet the acceptance criteria set by the product owner. For security purposes, development should not be able to release directly into production. Similarly, they should not have access to confidential production data. This is where separation of duties comes in. Operations teams are responsible for creating tests that allow aspects such as performance and security to be evaluated before code is released into the production environment. This can be automated using CI/CD for further fidelity in your deployments.

Management by PRAKTIK

It's important to maintain control over which responsibilities belong to whom. However, this can quickly become complicated. This is where PRAKTIK can step in. We can act as an independent third party to manage your pipelines and safeguard audit data for all releases. This pipeline management can be ensured using gates that must be approved by us before your code is released into the next environment of your pipeline.

It is important to get auditors working with your development and operations teams as soon as possible to ensure a seamless flow from the development, to testing, and all the way to your end product. For more information or to speak to an expert, contact us here at PRAKTIK.


Jira to Azure DevOps Migration

So you’ve decided to migrate from Jira to Azure DevOps. Where should you start? You’ve done some research on migration methods and tools, but haven’t yet found one that checks all the boxes for your organization. PRAKTIK has you covered: We’ve developed a custom solution to move your issues from Jira to Azure DevOps.

Features

Our solution is tailored to your specific needs. It can handle migration of labels to tags, multi-choice fields, attachments, and links. There is also a smart filtering of unused field values; that is, only active field values are migrated. The solution supports batch processing to avoid resource overload, and it can be restarted from a failure point. Furthermore, it includes state workflow mapping from Jira to Azure DevOps, as well as separate rules for each issue type. You want to convert the newest Jira Fix Version into an ADO Iteration? We can do that, too.

Jira to Azure DevOps Migration

Customization

Because we aim for maximum flexibility, custom coding is a must. To do this, we work with you to create a set of migration rules – mapping Jira issue types, fields, states, and link types to Azure DevOps. Next, we code that in and execute a dry-run migration. Your team can then validate and sign off, all without any impact to the existing system. This approach will ensure the final migration will run without a hitch.

This solution is the only one on the market that has been designed with the express purpose of large-volume migration of 10,000 items or more. To get started today or to speak with one of our experts, contact us here at PRAKTIK.


How to Migrate Azure DevOps Projects to a Different Organization

The problem

At present, migrating projects from one organization to another is not supported in Azure DevOps. The workarounds can be arduous, with less-than-perfect results. For instance, if you just need to migrate your repo, you could simply use the built-in clone functions. You could also choose to export your data from Excel,but that option means you lose your history. Alternately, there are third-party tools such as Migration Tools for Azure DevOps and OpsHub, but these tools are not meant for a full, high-fidelity migration.

The solution

What you really need is a high-fidelity way to migrate all your project data – including all historical information (with a few exceptions) – from one instance to another. Luckily, PRAKTIK has you covered.

By utilizing the Azure DevOps REST API, we’ve created a tool that will allow you to take all of your project data and move it from one organization to another. You can move one project, just a few, or all of your projects; the choice is yours. You’ll keep your work item and GIT source code history, your build and release definitions, test information, and everything in between. The only thing that will appear different is your work item IDs. However, the original IDs can still be viewed.

To implement this at your organization, we will run a full dry run so that you can run tests and complete any validation requirements. Migration options including moving projects from a collection on-premises to an organization in the cloud; from one organization to another in the cloud; from one collection to another on-premises; or from an organization in the cloud to a collection on-premises.

To get started with your own high-fidelity migration, or to speak with an expert, contact us at PRAKTIK today.


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.