What is Continuous Integration(CI)?
Continuous Integration is a Software Development practice where developers integrate code into a shared repository frequently and each integration is verified by an automation build to detect integration errors as quickly as possible.
Continuous Deployment(CD) Vs Continuous Delivery
Continuous Deployment (CD) – Any updated working version of the application is automatically pushed to Production. In an ideal world, continuous deployment would be adopted by majority of companies, but sometimes due to some constraints this is not possible.
Continuous Delivery – Involves some manual steps as in this practice the software is always release-ready, yet it is to be decided by the business personnel the timing of when to push it into production and so the final deployment is a manual step.
When the development is done and the testing team wants to check the functionality then build is released to the different test environments and this activity is handled manually for most of the projects. Manual build deployments takes lot of time and requires user interactions. Also manual build deployment have challenges such as handling the build version number, cost of the development is more because of maintenance, requires more team engagement and organization.
To overcome all the challenges and dependencies of manual build deployment process the Automated Build deployment is the best solution and the Build automation is the process of automating the creation of a software build.
TFS – Version Control System
The starting point for configuring CI and CD for your applications is to have your source code in a version control system. TFS supports two forms of version control – Git and Team Foundation Version Control. The Build service integrates with both of these version control systems. Once you have configured CI, any changes you push to your version control repository will be automatically built and validated.
TFS – Requirements
TFS Version: 2017
Server OS: Windows Server 2016 Standard Edition
Client OS: Windows 10 Professional
SQL Server: 2016
Account for TFS: Service Account or Domain account
Build & Release Agent Service
To build and deploy your code you need at least one Windows agent. As you add more code and people, you’ll eventually need more.
Why prefer vNext Build over XAML Build?
- vNext Build
- Edit build definitions in the Web
- Easily customizable and templates are available in stores
- Improved Triggers
- Improved Retention Policies
- Cross Platform
- Easy to migrate
- Auto-updating agents
- No limitations for building Pools and Queues
- XAML Build
- Removed support for TFS 2018
- XAML build is deprecated
Tasks involved in TFS Build Definition
- Visual Studio Build Solution
- Code Analysis Task and Report Generation
- Code Metrics Task and Report Generation
- Build SQLServer DACPAC
- Update Assembly
- Token Replace in config files
- Setting Encrypted and Non-Encrypted variables
- Copy the files from Source Directory to Artifact Staging Directory
- Continuous Integration
- Gated Check-in
- Retention & History
Tasks involved in TFS Release Definition
- Take backup of Web Project
- Powershell Script for DB Backup
- Copy files from Build Drop Location to Destination Directory
- SQLServer Deploy DACPAC
- Generate Release Note
- Continuous Deployment
- Retention & History
Continuous integration helps keep us honest. It validates our assumptions and changes. And it’s a process we can use every moment of our work day to ensure that the software we’re building is improving and not decaying.
With the CI & CD implementation using the TFS the build process is easy to handle and more effective testing on frequent builds can be performed.
- TFS 2017 Installation along with Agent Installation
- Release Management and Build Automation with TFS 2017
- Create Build Agent in TFS 2017
- Database DevOps with SQL Server Data Tools and TFS 2017
- TFS Marketplace Extensions