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.
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. If a code branch stays checked out for longer, threats related to multiple integration failures and conflicts increases. Such conflicts are possible when the programmer branch reintegrates into the primary line. Before submitting the code into the repository, the developers must first consider updating the same for reflecting the modifications in that repository as they take their copy. The greater number of modifications the repository consists of, the greater amount of work developers have to do before they submit their modifications.
There is a risk that ultimately, the repository will end up becoming so disparate from the baselines of the developers that they move into a “integration hell” or “merge hell” in which the time duration it needs for integrating surpasses the time duration it originally took for making the changes. In the worst scenario, the developers might require discarding their changes completely and redoing the work. Continuous integration requires early and frequent integrations, for avoiding the problems 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 (commonly abbreviated as TFS) is basically a Microsoft product that provides management of the source code (either with Team Foundation Version Control or Git), requirements management, reporting, project management (both for agile software development as well as waterfall teams), release management, automated builds, lab management, and testing 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.
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.