Depending on what version of TFS you intend to migrate and what features you are using, there are a few things that in my opinion are “major” considerations because they have the potential of adding scope to your migration efforts. While you will find out about them as you read through the official migration guide, I believe there is value to knowing these things prior to embarking in such journey.
The reason for this post is to help customers realize how to satisfy the CFR – Code of Federal Regulations, Title 21, PART 11 ELECTRONIC RECORDS; ELECTRONIC SIGNATURES requirements with Team Foundation Server, Azure DevOps Service and Azure DevOps Server.
I was working on a DevOps scenario that involved automating the deployment of batch process files from one server to one or more other servers. To accomplish this, I created a build pipeline to collect certain files from the staging location and store them as Build Artifacts. I then created a release pipeline to ask for deployment approval and then deploy the build artifacts to servers in other environments.
Azure Lab services is a quick and easy way to manage environments for your team in the cloud. It is versatile enough to set up development environments, testing and even classroom lab environments. The service handles all the infrastructure, user management, and now scheduling when the lab is available. The ability to stop a lab VM has been around for some time, but the ability to schedule when a VM starts, how long it remains up and then when it is to shut down recently became available.
Prior to Team Foundation Server (TFS) 2017, moving or cloning of a TFS instance required manual preparation and configuration of existing instance’s backups. You can now configure your restored databases completely through the application tier.
This blog walks through the new process to demonstrate how to restore and configure an instance of TFS to new hardware.
This article is part 2 of DevOps and Culture. See part 1 here. In this entry I’ll discuss how we can think of culture in a systematic way and how we can change it.
Peter Drucker famously said, “Culture eats strategy for breakfast.” This is a great introduction to how we think about DevOps and in this article, I’m going to unpack this statement so that we have a bit more context. This is the first part of multiple articles on culture as it relates to DevOps.
This project simplifies the setup of a SonarQube server to one step. Simply click the Deploy to Azure link on the project homepage and follow the simple walkthrough to have resources deployed out and configured.
If part of this transition requires that aspects from the legacy process be kept, it’s a great opportunity to demonstrate that through the use of agile process and agile tools, we can have an even better control of the value (beyond just software) that the development team is creating for the company.
I have been working on a small project in my free time in which I’m the only developer. When I started the project, I wanted to write the entire application in a test driven, test first, manner. I wrote my failing test, then made the test pass and as I saw opportunities to refactor, I took the time to reduce complexity, separate concerns and reorganize as needed. I was in a red-green-refactor rhythm and it was enjoyable to see the test count go up and my code coverage for tests at 100%… but then reality set in.