alexa

Automation Testing: Performing Continuous Integration and Deployment with Team Foundation Server

team foundation server two
02Nov, 2018

Automation is a good aid when trying to achieve Continuous Integration and Deployment and as part of the overall scheme, this practice can vastly improve the quality of code and the speed of development. Continuous integration (CI) is usually referred to as the practice of regularly integrating and testing one’s solution to include changes made to its definition. These changes can include updating the source code, changing database schema or simply updating a text-based configuration file.

For the best results when one or more changes are checked into your configuration management system, the solution should then be rebuilt and recompiled, retested and finally any code or schema analysis performed on it. If it is impractical to do this every time a change is saved you should strive to do so at least once if not several times a day, that is the essence of continuous integration.

Moving this process one step forward continuous deployment (CD) enhances CI by automatically deploying successful builds. For example, when the build is successful on a programmers workstation, then the team may automatically deploy their changes to the project integration environment, which would invoke the CI system there.

Security Testing

On a developer’s workstation, the integration job could run by example at specific times, perhaps once an hour, or better every time that they check in something that is part of the build. The whole process of continuously integrating a developer’s code with the rest of a team’s code and then running automated test regressions in an integration environment is the essence if CI.

This is a critical part of agile to ensure integration is done right. When used with Selenium or another good automation tool good testing results can also soon be achieved. The longer a branch of code remains checked out on a programmer’s computer, the greater the risk of multiple integration conflicts and failures when the branch is finally reintegrated into the main trunk. When programmers submit code to the repository they should firstly update their code to reflect the changes in the repository since they took their local copy. The more changes the repository contains, the more work programmers must do before submitting their own changes.

There is a risk that eventually the repository may become so different from the programmer’s local copy that the team can enter what is sometimes referred to as “merge hell”, or “integration hell”. This is where the time it takes to integrate exceeds the time it took to make their original changes and conflicts are everywhere. This is where continuous integration becomes a critical practice. It involves integrating early and often, so as to avoid the pitfalls of “integration hell”.

Regular integration requires a reliable repository where the main trunk of code and any development branches are stored. Offsite backups of this code are also essential, should the unthinkable ever happen and the source server should go down or go missing at least code would still exist and a few hours work may be lost rather than a few years.

There are many options for repository management on the market today. One of the most preferred tools for this purpose include the built-in repository options of Team Foundation Server. This multi-functioned and well-designed application allow for safe storage of both Visual Studio code and also Eclipse code.

Team Foundation Server

Team Foundation Server (which is commonly abbreviated to TFS) is a Microsoft product which provides integrated project and source code management. TFS also provides reporting, requirements management, project management (for both agile software development and waterfall teams), automated builds, testing and release management capabilities. In fact, TFS has the ability to cover the entire application lifecycle.

TFS is a complex and complete yet intuitive suite which can be used as a backend to numerous integrated development environments but is tailored for the Microsoft Visual Studio and Eclipse development platforms.

To help with agile teams of various sizes TFS supports multi teams and multi-projects with ease and is very well suited to the agile development framework. TFS and other tools with similar features allow the entire team to keep up to speed on the current sprint progress and everyone including the testers can access the progress screens, burn down charts and any attached artefact such as test cases.

API Automation

Case Study

As with any agile project, the development phase is conceived, agreed and recorded within TFS. For instance, let us assume a software company XYZ is getting ready to design stage twoof their flagship product ABC. The data comprises a chosen name for the project and development date span and the application.

TFS breaks down the development phase into monthly sprints, with each sprint being given a descriptive name which gives an idea of what it is hoped will be achieved during these sprints. Typically, these sprints are one month in length and each will focus on a particular stage of development.

Further, one of the first tasks is to decide who will be working on the project. The size and complexity of the team will vary depending on the size and complexity of the actual project. For example, let us say we have the product owner, a programmer and a tester. This important data allows the team to manage resources and ensure that enough capacity exists to complete the agreed tasks within a sprint. When the team makeup is decided it is then possible to add backlog items to the sprint and assign these to team members. Once all the agreed backlog items have been added to the correct sprint and assigned, they will then become visible in the sprint backlog.

Each of the backlog items can be edited and external artefacts such as test cases can also be attached. This means the entire team can have access to any document that is relevant to the sprint. Another important piece of data on these cards is the Remaining Work value. The actual value that is used here can vary from company to company but in many cases, this will relate to estimated hours remaining. These are usually updated daily just after the daily scrum. This is high-value data which will help provide up to date burndown charts which in turn keep all interested parties up to speed on sprint progress.

Finally, all of this updated and valid data is visible in the monthly burn down chart. This chart and any other data are only as good as the information that is input into the system. For agile to work correctly everyone has to be 100% behind the processes and everyone has to ensure the data is kept up to date and is as accurate as it can possibly be.