Cut Your Azure Resource Costs in Half

We’re all looking for ways to reduce our development expenses. Sometimes, our expenses are driven up by keeping unused virtual machines, App Services, and SQL Servers in Azure. Alternately, these resources are over-provisioned, meaning we’re paying for more capacity than we actually need. Maybe there are resources you’re not quite sure where they go, but you’re afraid they’re important so you just hang onto them. All of this can increase our subscription costs, particularly for Azure resources in Dev and Test environments. The worst part is that it’s tough to track down these unused resources, especially when the volume of them is so great. So, they end up continuing to run and continuing to eat up cost.

With PRAKTIK’s managed services offering, you can cross this off your to-do list. We will periodically review all your Dev and QA resources to delete any unused items. We will also reorganize and consolidate resources to make sure your subscription costs are where they should be for your use case. Some customers find a 25%-50% decrease in their Azure resource costs by using this service.

At PRAKTIK we realize that every situation is different, so we tailor each managed services offering to meet the needs of each individual client. We can optimize your builds and releases, migrate your Azure DevOps projects, and so much more. If there isn’t a ready-made solution for your problem, we will create it and execute it for you. You will also have your own personal expert to answer any questions that may arise.

To learn more, or to get started today, contact our team of experts.


Azure DevOps Server 2020 Update 1

The most recent update to Azure DevOps Server includes many new features, as well as bug fixes. Some of the highlights include state transition rules in Boards, pull request experience improvements, and generic webhook-based triggers for YAML pipelines. You can directly install Azure DevOps Server 2020.1 or upgrade from Azure DevOps Server 2020, 2019, or Team Foundation Server 2015 or newer. The Data Migration Tool is estimated be available for this update of Azure DevOps Server by the end of June 2021.

State Transition Restriction Rules

The new state transition restriction work item type allows you to restrict work items from being moved to a different state. For example, you can restrict bugs from moving straight from New to Resolved. Instead, they will need to go from New to Active to Resolved. You can also use these restriction rules to restrict state transitions by group membership. This new feature helps to close the feature parity gap between hosted XML and the inherited process model.

Webhook-Based Triggers for YAML Pipelines

In the past, you were unable to automate your deployment process based on external events or services. Now, however, webhook trigger support in YAML pipelines has been enabled to allow you to integrate your pipeline automation with any external service. To learn how to configure your webhooks, see the documentation.

Pull Request Experience Improvements

This update to Azure DevOps Server is full of features to help improve your pull request experience. For example, the tree listing of files in a PR now shows a (+) to help individuals identify new files. Furthermore, aspects of the mobile view have been improved. This includes better usage of space to allow you to view more information. There is also an enhanced branching experience when creating a PR to enable you to compare changes with the compare branch instead of the default branch.

For a comprehensive list of features and bug fixes, visit the documentation. To learn more about installing or upgrading an Azure DevOps Server deployment, contact us at PRAKTIK.


How to Automate Power BI Deployment with Azure DevOps

Power BI is a business analytics solution that allows you to visualize and analyze data. This analysis can be helpful in determining what’s important, and it can be shared to aid in collaboration. In the Power BI service, you can test your content before releasing to customers using Microsoft’s Power BI deployment solution. However, the data in your particular Power BI service may be larger and more complex than the standard deployment solution supports. For these scenarios, PRAKTIK has developed a custom Power BI solution.

Microsoft’s Solution

In order to access the deployment pipelines feature, you’ll need to be an admin of a new workspace or have a Premium license. During deployment, Power BI will copy items such as datasets, reports, and dashboards into the target stage, provided they originate from a PBIX file. However, some items will not be copied, such as the URL, IDs, and certain permissions. Furthermore, the maximum number of Power BI items that can be deployed in one deployment is 300. This Power BI deployment solution is great for simpler, more standard use cases.

PRAKTIK’s Solution

For those scenarios that do require more fine-tuned control, PRAKTIK has developed a custom Power BI deployment solution. For example, we can handle large Power BI reports that are part of a greater app and includes databases, websites, and Power BI reports components. In addition, the solution is fully customizable to your needs. You can even have an environment to roll back any unwanted changes. This deployment will be fully automated, and will only require manual approvals or checkpoints from you if you so desire.

For more information, or to get started with your custom Power BI deployment solution, contact us here at PRAKTIK.


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.