The foundation of Agile Software Development: the construction of continuous integrated environment

What agile means.

Agile can be said to be one of the most "hot" words in software engineering in recent years, with countless articles, books and discussions about it. Still, there are plenty of practitioners who misunderstand and confuse agile. What does agile really mean? Is it just some pretty, funky publicity? What exactly is agile? What benefits can agile bring to the software development team? There are a lot of similar problems.

Agile is nothing new or fashionable at all, it has existed for decades. For decades, none of those software development teams that have been successful are agile development teams. They have applied agile ideas to their software development process, but have not formally expressed their working methods, values and guiding ideology. By the early 2001, the situation had improved, and a group of leaders and development gurus who had struggled for decades in the field of software development (especially the leaders of object-oriented societies and Smalltalk societies) could no longer tolerate the confusion of software itself and the software development caused by bureaucracy, They have summed up their decades of understanding and experience of software and team software development as an "Agile manifesto" to appeal to how software practitioners should develop and understand software. All the ideas and values of agile are contained in this manifesto.

But the manifesto still seems a little less practical for most people. As a software development team, we can accept the values in the Agile manifesto, but what is agile??? In other words, how does agile implement the team's daily development efforts? Almost every team that tries to develop agile software has been bothered by this problem. From the point of view of the team's day-to-day development activities, agile is:

"Short Cycles that are test-driven and feedback-driven, yielding constant."

Among them, short cycle is the core. The whole software development activity should be divided into a series of short iterative processes, each iteration completes a certain number of features. The cycle of iterations should be as short as possible. More importantly, iterations should be driven by testing and feedback (TDD and communication). Only in this way can we provide a good foundation and secure network for continuous improvement (through refactoring). Note that this process differs from the general code-and-fix in that each iteration cycle produces a validated, usable product, but it may not be functional, and it is a conscious, continuous, feedback based improvement process rather than a simple fix. In fact, all successful project development activities are close to this standard, but the agile put it in the most important position.

To effectively achieve the effect described above, in addition to the need for some technical skills (such as: refactoring skills, TDD skills, etc.). We also need an environment that can effectively support this form of activity, which should be the foundation of all projects that want to succeed, that is, a continuous integration environment. Continuous integration provides the foundation for the effective achievement of agile. So what is continuous integration?

What is continuous integration

Technically speaking, "continuous integration" means that each member of the development team tries to integrate their work changes as frequently as possible into the source library, and verifies that the changes in the new combination do not cause any disruption. The library here refers to the repository of software source code that is managed by version control tools such as ClearCase or CVS. The frequency of this is related to the type of software developed by the team, but in general the frequency should be less than 1 hours.

Note that the concept of continuous integration differs from the concept of "build daily" and "build every night" that you have heard about before. According to Martin Fowler, this difference is mainly reflected in three aspects:

Continuous integration occurs frequently during the day, but every night the build occurs once a day.

The goal of a nightly build is to produce a stable, available release, and continuous integration provides quick feedback on the success or failure of integration in addition to achieving this goal.

The nightly build does not specify how often the developer should check in, while continuous integration encourages high frequency check in to achieve rapid feedback.

As you can see, the continuous integration of high-frequency check in and fast feedback features provides a solid technical basis for effectively reaching agile. It can be said that without a good continuous integration environment as the basis, it is almost impossible to develop team software efficiently. So how do you build an environment like this? Later in this article, I'll give you step-by-step step-by-step instructions for a detailed tutorial, but before that, let's take a look at the tools needed to build an effective, continuous integration environment.