Coding has evolved from incubators to online hubs which allow for remote coding. The size of applications has become increasingly difficult for a single person to code. Experts in various coding areas, therefore, converge on the virtual platform in order to contribute to the more massive code repository.
DevOps uses Agile principles and combines infrastructure, development, QA, and operations engineers together through the entire cycle of software development, deployment, and support, eliminating many of the silos between teams. Most importantly, DevOps improves communication and enables better collaboration, helping enterprises to bring products and innovation to market much more rapidly.
The most recent problem revolves around Git 4 Windows (Or any other Git client) and certificate revocation checking against Team Foundation Server (Or other source control) secured with a .mil URL, or any URL secured with a Department of Defense (DoD) signed certificate.
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.