Implementing DevOps not only requires a cultural change but also the right tool. Here we list the main benefits of implementing DevOps with TFS On-premises.
In recent years, the implementation of DevOps practices has become popular within the software industry. It offers many advantages and benefits to software development, like the modernization of deployment processes, less time to Go Live, less exposure to errors, and reduced costs.
There are many tools that allow the implementation of DevOps, and the choice of the most appropriate ones depends on many factors, such as the programming languages, the code version control tool, the environment where the deployments will be made (On-premises or in the Cloud), the development team knowledge, and the regulations or restrictions of the business itself.
Most companies that have their systems developed in .Net technology have the option to implement DevOps based on the set of tools provided by Microsoft. In some industries, like banking, they are more likely to opt for an On-premise solution to prevent sensitive information from being stored by third parties.
Below, we list the main benefits evidenced, from our experience, when implementing DevOps with TFS On-premises.
Content related: Azure Devops Implementation: three lessons learned
1. Generates automatic builds
TFS On-premise allows you to create a build definition for a given application, a definition in which you can automate the tasks necessary to generate the artifacts that will be deployed.
TFS provides, out of the box, a wide variety of predetermined tasks designed for all types of applications (websites, desktop apps, web services, etc.), such as installing Nuget packages, running automatic tests, compiling and using VS Build or the MSBuild command, and publishing the artifacts, just to mention some of the most used.
In the same way, TFS On-premise allows the creation of custom tasks using PowerShell, which greatly increases the power and flexibility of this tool. These tasks can later be grouped to generate reusable packages.
With a little experience and creativity, you can create custom task groups that cover a wide range of applications. That is, we can have a set of preassembled tasks to create build definitions in a very short time, thereby significantly increasing the maintainability of this automatic build scheme.
2. Integrates with version control tools
As with Visual Studio, TFS On-premise allows integration with some of the most widely used version control tools (GIT, Subversion, and of course, TFVC). Thanks to this integration, we can create tasks that automatically download the code from a particular repository. We can also indicate which specific version of the code to download. That code, now hosted on the TFS server, will be the one compiled to generate the binaries to be published.
If the version control tool used is not one of those integrated with TFS, it is possible to create custom tasks that allow access to the required version of code and download it. At some point, I had to integrate with AccuRev, and I was able to create Powershell scripts that allowed me to implement the necessary logic to locate the required version of the code and download it.
3. Supports multiple languages
TFS allows you to create build definitions for applications written in all the .Net family languages (C#, Asp.net, .Net Core, Xamarin, etc.) and has support for other languages widely used today as well, such as Java and NodeJs.
If this is not enough for your particular project needs, you can always create custom tasks and even integrate with Jenkins to generate binaries in any programming language.
4. Powershell’s contribution to personalization
Some may not be familiar with Powershell; however, it is worth highlighting the power and flexibility of this programming language, which is no longer just a scripting language and specifically incorporates the benefits of .Net, regarding object handling.
Thanks to Powershell, the DevOps team can create tasks for almost anything. You can also manage the scripts in a different repository or in the same repository where the application code is located, allowing access to the latest version of each custom task at any time.
5. Incorporation of automatic tests into the build process
In any project or solution to be built, we can count on a set of automatic tests, either unitary or integration tests.
Our definition of build can include the execution of tests and then continue with the generation of artifacts, if and only if the result of the tests is satisfactory. In this way, we guarantee that the generated artifacts meet a minimum of requirements to verify the quality of the application to be deployed.
How proven the application is, prior to its deployment, will depend on the degree of testing coverage that the development team has achieved.
6. Manages configuration files
A common problem when generating the artifacts to be deployed has to do with the configuration files, which generally contain information that varies according to the environment in which the deployment takes place.
When we refer to configuration files, we are talking about .config, .json .properties, or any other type of file with relevant information for the execution of the application, which cannot be included within the binaries. Typical examples of this type of information are the routes of some endpoints or a connection string to access a database.
This is a very common problem, and the most appropriate solution will depend on the context of the project. One possible alternative is to implement customized tasks that allow the generation of configuration files for each environment, publish them within the artifacts, and deploy them where appropriate.
In my recent experience, this was achieved by following a key tokenization scheme that was later replaced by associated values. We implemented specific tasks in PowerShell, both for build and release.
7. Provides templates with common tasks for builds
Although TFS provides all the tools to create our build definitions from scratch, it also provides a series of templates that include some of the most common tasks according to the type of application.
Within this feature, we find templates for Android projects, Java with Ant, Gradle or Maven, ASP.Net, ASP.Net Core, Azure Service Fabric, Jobs at Jenkins, Windows Platform, Xamarin for Android, and iOS and XCode.
8. Allows automatic releases
I have already highlighted the possibilities TFS On-premises offers to obtain the code of an application, compile it, execute tests, generate a battery of configuration files, and publish all those artifacts for their use in the deployment.
In most cases, deployment is nothing more than copying the artifacts on a certain route; however, determining what that route is may not be simple, especially in a medium to high complexity infrastructure context.
In today’s organizations, several applications coexist with dependencies between them and are deployed on multiple servers, even with latent conflicts due to the versions of libraries and packages used.
Deploying the artifacts that make up an application is not only laborious and can cause a lot of downtime, but it is also risky. Therefore, automating these processes is essential to find an efficient and fast mechanism that allows organizations to keep their systems updated without high downtime and with little exposure to errors.
TFS On-premises allows you to create release definitions that, like build definitions, contain a series of tasks that are executed sequentially or in parallel to carry out the installation and update of a system.
These tasks can include actions, such as:
- Stop services or other applications that could interfere.
- Making a backup copy of the version to be replaced.
- Copying the binaries to the specified route.
- Selecting and copying the appropriate configuration files.
- Getting back to the stopped services or applications.
- Recycling the IIS or the AppPool if it is a web application.
9. Provides templates with common tasks for releases
The variety of templates for release definitions is not as wide as for build definitions, and this is because, in this instance, there are no great differences in terms of the activities to be performed, depending on the technology.
Nevertheless, TFS offers a series of templates with the most common tasks we can find in a deployment, both for physical servers and for the Cloud.
10. Facilitates rollbacks
We all want our deployments to be successful 100% of the time, but no matter how well we do, unforeseen events might arise. When there are failures in productive services, it’s important to have mechanisms that allow us to return to the last safe point quickly, i.e., to the last stable version of the application.
When listing the possible tasks of a release, a good practice is to keep backups of previous versions in some physical location. If something goes wrong during or after the deployment, we can go back to the previous version by doing a manual deployment of those files.
Then you may ask, all of the above has described the benefits of automation only to now say that the rollback has to be manual? It’s one option, but there’s a better one. From the perspective of TFS releases, it is possible to consult the last ones that were executed for each application, and from there, select a satisfactory release and request a re-deploy. In this way, we can quickly return to a stable version of the application.
11. Offers greater security
Within the IT teams of any organization, there are different roles, and as such, everyone has different responsibilities and permissions over the build and deploy activities of the applications. To satisfy this, TFS on-premise provides a matrix of permissions by role or user group, which allows easy segmentation of those responsible for each task and won’t expose sensitive information to anyone.
Wrapping Up
Organizations are more often basing their processes on systems that interact with each other and have cross-dependencies. The high demand of users causes the infrastructure to be increasingly complex, with caching and redundancy schemes, just to mention some of the mechanisms that try to satisfy the demand on time.
Likewise, we are in an era of great volatility in terms of technologies, so the libraries and packages of third parties are constantly being updated, which can cause conflicts, especially in contexts where different applications are deployed in parallel.
There are mechanisms for authentication, disaster recovery, security, activity monitoring, and a long etcetera that make deployments of new applications or updates to existing ones more frequently and with more complexity, given the needs of the market.
Leaving this entire network in the hands of people has several disadvantages since as humans, we are not exempt from making mistakes. Moreover, we require more time than a machine, and it is difficult for people (operations, to mention a common example) to be aware of all the particularities required to deploy many different applications.
Without a doubt, this is a fast and secure solution for organizations that want to access the benefits of DevOps without migrating their services to the Cloud. Implementing DevOps with TFS On-premise is an invaluable alternative for solving this problem, since it allows the development and operations teams to work together on the build and release definitions, with all the necessary level of detail and collection. The machines will do the rest.
Comments? Contact us for more information. We’ll quickly get back to you with the information you need.
