Multi-stage continuous integration

Last updated

Multi-stage continuous integration is a software development technique intended to achieve highly integrated parallel development activity while reducing the scope of integration problems. [1]

Contents

Theory

Multi-stage continuous integration takes advantage of a basic unifying pattern of software development: software moves in stages from a state of immaturity to a state of maturity, and the work is broken down into logical units performed by interdependent teams that integrate the different parts together over time. What changes from shop to shop is the number of stages, the number and size of teams, and the structure of the team interdependencies.

Multi-stage continuous integration is an expansion upon continuous integration, it presumes that you are already following those recommended practices.

The larger and/or more complex the project, the higher the chance that the project becomes unstable. Alerts and broken builds increase as the project grows. Progress decreases and the mainline gets increasingly unstable. The risk of build failure increases exponentially as the number and locations of developers grow. [2]

Each developer works on their own task. As they make changes, continuous integration is done against that team's branch. If it does not succeed, then that developer (possibly with help from her teammates) fixes the branch. When there is a problem, only that team is affected, not the whole development effort. This is similar to how stopping the line works in a modern lean manufacturing facility. If someone on the line pulls the "stop the line" cord, it only affects a segment of the line, not the whole line.

It is note-worthy that in recent years the "topic" or "feature" branch model has gained in popularity over the team based branch model. See for example the popular Git-Flow branching model [3]

On a frequent basis, the team will decide to go to the second phase: integration with the mainline. In this phase, the team does the same thing that an individual would do in the case of mainline development. The team's branch must have all changes from the mainline merged in (the equivalent of a workspace update), there must be a successful build and all tests must pass. Integrating with the mainline will be easier than usual because only pre-integrated features will be in it, not features in-process. Then, the team's changes are merged into the mainline which will trigger a build and test cycle on the mainline. If that passes, then the team goes back to the first phase where individual developers work on their own tasks. Otherwise, the team works on getting the mainline working again, just as though they were an individual working on mainline.

Changes propagate as rapidly as possible, stopping only when there is a problem. Ideally, changes make it to the main integration area just as frequently as when doing mainline development. The difference is that fewer problems make it all the way to the main integration area. Multi-stage continuous integration allows for a high degree of integration to occur in parallel while vastly reducing the scope of integration problems. [4]

For multi-stage continuous integration, each team must have its own branch.

Advantages

Multi-stage continuous integration has many advantages: [ citation needed ]

Tools

Tools that support multi-stage continuous integration include:

See also

Related Research Articles

A software company is a company whose primary products are various forms of software, software technology, distribution, and software product development. They make up the software industry.

Systems development life cycle Systems engineering term

In systems engineering, information systems and software engineering, the systems development life cycle (SDLC), also referred to as the application development life-cycle, is a process for planning, creating, testing, and deploying an information system. The systems development life cycle concept applies to a range of hardware and software configurations, as a system can be composed of hardware only, software only, or a combination of both. There are usually six stages in this cycle: requirement analysis, design, development and testing, implementation, documentation, and evaluation.

In software engineering, continuous integration (CI) is the practice of merging all developers' working copies to a shared mainline several times a day. Grady Booch first proposed the term CI in his 1991 method, although he did not advocate integrating several times a day. Extreme programming (XP) adopted the concept of CI and did advocate integrating more than once per day – perhaps as many as tens of times per day.

Release engineering, frequently abbreviated as RE or as the clipped compound Releng, is a sub-discipline in software engineering concerned with the compilation, assembly, and delivery of source code into finished products or other software components. Associated with the software release life cycle, it was said by Boris Debic of Google Inc. that release engineering is to software engineering as manufacturing is to an industrial process:

Release engineering is the difference between manufacturing software in small teams or startups and manufacturing software in an industrial way that is repeatable, gives predictable results, and scales well. These industrial style practices not only contribute to the growth of a company but also are key factors in enabling growth.

The incremental build model is a method of software development where the product is designed, implemented and tested incrementally until the product is finished. It involves both development and maintenance. The product is defined as finished when it satisfies all of its requirements. This model combines the elements of the waterfall model with the iterative philosophy of prototyping.

Application lifecycle management (ALM) is the product lifecycle management of computer programs. It encompasses requirements management, software architecture, computer programming, software testing, software maintenance, change management, continuous integration, project management, and release management.

Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all members of a cross-functional agile team, with special expertise contributed by testers, to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace. Specification by example is used to capture examples of desired and undesired behavior and guide coding.

AnthillPro is a software tool originally developed and released as one of the first continuous integration servers. AnthillPro automates the process of building code into software projects and testing it to verify that project quality has been maintained. Software developers are able to identify bugs and errors earlier by using AnthillPro to track, collate, and test changes in real time to a collectively maintained body of computer code.

DevOps is a set of practices that combines software development (Dev) and IT operations (Ops). It aims to shorten the systems development life cycle and provide continuous delivery with high software quality. DevOps is complementary with Agile software development; several DevOps aspects came from the Agile methodology.

PTC IntegrityLifecycle Manager is a software system lifecycle management (SSLM) and application lifecycle management (ALM) platform developed by MKS Inc. and was first released in 2001. The software is client/server, with both desktop (java/swing) and web client interfaces. It provides software development organizations with a collaborative environment in which they can manage the end-to-end processes of development, from requirements management, engineering change management, revision control, and build management to test management and software deployment as well as associated reports & metrics.

Micro Focus Application Lifecycle Management (ALM) is a set of software tools developed and marketed by Micro Focus for application development and testing. It includes tools for requirements management, test planning and functional testing, performance testing, developer management, and defect management.

AccuRev SCM

AccuRev is a software configuration management application developed by AccuRev, Inc. and was first released in 1999. In December 2013 AccuRev was acquired by Micro Focus.

Continuous testing is the process of executing automated tests as part of the software delivery pipeline to obtain immediate feedback on the business risks associated with a software release candidate. Continuous testing was originally proposed as a way of reducing waiting time for feedback to developers by introducing development environment-triggered tests as well as more traditional developer/tester-triggered tests.

Continuous delivery (CD) is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time and, when releasing the software, without doing so manually. It aims at building, testing, and releasing software with greater speed and frequency. The approach helps reduce the cost, time, and risk of delivering changes by allowing for more incremental updates to applications in production. A straightforward and repeatable deployment process is important for continuous delivery.

In software engineering, a schema migration refers to the management of version-controlled, incremental and reversible changes to relational database schemas. A schema migration is performed on a database whenever it is necessary to update or revert that database's schema to some newer or older version.

Disciplined agile delivery (DAD) is the software development portion of the Disciplined Agile Toolkit. DAD enables teams to make simplified process decisions around incremental and iterative solution delivery. DAD builds on the many practices espoused by advocates of agile software development, including scrum, agile modeling, lean software development, and others.

Perforce, legally Perforce Software, Inc., is an American developer of software used for developing and running applications, including version control software, web-based repository management, developer collaboration, application lifecycle management, web application servers, debugging tools and Agile planning software.

In software deployment, an environment, or tier is a computer system or set of systems in which a computer program or software component is deployed and executed. In simple cases, such as developing and immediately executing a program on the same machine, there may be a single environment, but in industrial use, the development environment and production environment are separated, often with several stages in between. This structured release management process allows phased deployment (rollout), testing, and rollback in case of problems.

A DevOps toolchain is a set or combination of tools that aid in the delivery, development, and management of software applications throughout the systems development life cycle, as coordinated by an organisation that uses DevOps practices.

TestOps refers to the discipline of managing the operational aspects of testing within the software delivery lifecycle.

References

  1. ↑ Multi-Stage Continuous Integration accessdate 2009-02-25, Poole, Damon, 2008-12-02 Dr. Dobb's, Published by TechWeb
  2. ↑ Advanced Multi-Stage Integration, accessdate 2009-03-19, Poole, Damon, 2009-01-17 Agile Development Thoughts
  3. ↑ "A successful Git branching model".
  4. ↑ Large Scale Continuous Integration, Poole, Damon, 2009-01-19 CMCrossroads Published by CMC Media[ permanent dead link ]
  5. 1 2 AccuRev and Electric Cloud Partner to Advance Multistage Continuous Integration and Scalable Agile Best Practices, accessdate 2009-03-19 Archived 2008-07-20 at the Wayback Machine
  6. ↑ Pain Free Building Guide: Team Based Streams
  7. ↑ "Jazz.net". Jazz.net.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.