Recent from talks
Continuous integration
Knowledge base stats:
Talk channels stats:
Members stats:
Continuous integration
Continuous integration (CI) is the practice of integrating source code changes frequently and ensuring that the integrated codebase is in a workable state. Typically, developers merge changes to an integration branch, and an automated system builds and tests the software system. Often, the automated process runs on each commit or runs on a schedule such as once a day. Grady Booch first proposed the term CI in 1991, although he did not advocate integrating multiple times a day, but later, CI came to include that aspect.
The earliest known work (1989) on continuous integration was the Infuse environment developed by G. E. Kaiser, D. E. Perry, and W. M. Schell.
In 1994, Grady Booch used the phrase continuous integration in Object-Oriented Analysis and Design with Applications (2nd edition) to explain how, when developing using micro processes, "internal releases represent a sort of continuous integration of the system, and exist to force closure of the micro process".
In 1997, Kent Beck and Ron Jeffries invented extreme programming (XP) while on the Chrysler Comprehensive Compensation System project, including continuous integration.[self-published source] Beck published about continuous integration in 1998, emphasising the importance of face-to-face communication over technological support. In 1999, Beck elaborated more in his first full book on Extreme Programming. CruiseControl, one of the first open-source CI tools,[self-published source] was released in 2001.
In 2010, Timothy Fitz published an article detailing how IMVU's engineering team had built and been using the first practical CD system. While his post was originally met with skepticism, it quickly caught on and found widespread adoption as part of the lean software development methodology, also based on IMVU.
The core activities of CI are that developers co-locate code changes in a shared, integration area frequently and that the resulting integrated codebase is verified for correctness. The first part generally involves merging changes to a common version control branch. The second part generally involves automated processes including: building, testing and many other processes.
Typically, a server builds from the integration area frequently, i.e. after each commit or periodically, like once a day. The server may perform quality control checks such as running unit tests and collect software quality metrics via processes such as static analysis and performance testing.
Build automation is a best practice. Build automation tools automate building.
Hub AI
Continuous integration AI simulator
(@Continuous integration_simulator)
Continuous integration
Continuous integration (CI) is the practice of integrating source code changes frequently and ensuring that the integrated codebase is in a workable state. Typically, developers merge changes to an integration branch, and an automated system builds and tests the software system. Often, the automated process runs on each commit or runs on a schedule such as once a day. Grady Booch first proposed the term CI in 1991, although he did not advocate integrating multiple times a day, but later, CI came to include that aspect.
The earliest known work (1989) on continuous integration was the Infuse environment developed by G. E. Kaiser, D. E. Perry, and W. M. Schell.
In 1994, Grady Booch used the phrase continuous integration in Object-Oriented Analysis and Design with Applications (2nd edition) to explain how, when developing using micro processes, "internal releases represent a sort of continuous integration of the system, and exist to force closure of the micro process".
In 1997, Kent Beck and Ron Jeffries invented extreme programming (XP) while on the Chrysler Comprehensive Compensation System project, including continuous integration.[self-published source] Beck published about continuous integration in 1998, emphasising the importance of face-to-face communication over technological support. In 1999, Beck elaborated more in his first full book on Extreme Programming. CruiseControl, one of the first open-source CI tools,[self-published source] was released in 2001.
In 2010, Timothy Fitz published an article detailing how IMVU's engineering team had built and been using the first practical CD system. While his post was originally met with skepticism, it quickly caught on and found widespread adoption as part of the lean software development methodology, also based on IMVU.
The core activities of CI are that developers co-locate code changes in a shared, integration area frequently and that the resulting integrated codebase is verified for correctness. The first part generally involves merging changes to a common version control branch. The second part generally involves automated processes including: building, testing and many other processes.
Typically, a server builds from the integration area frequently, i.e. after each commit or periodically, like once a day. The server may perform quality control checks such as running unit tests and collect software quality metrics via processes such as static analysis and performance testing.
Build automation is a best practice. Build automation tools automate building.
Recent media