Continuous Integration and Delivery

This assignment delves into the crucial concepts of continuous integration and continuous delivery (CI/CD). It explores how these practices revolutionize software development by emphasizing frequent code integration and automated deployment. The text examines the symbiotic relationship between CI and CD, highlighting their individual strengths and how they collectively enhance development efficiency and quality. Furthermore, it delves into the role of code revision systems within continuous integration, showcasing expert perspectives on optimizing these systems for faster and more effective integration.

USE OF CODE REVISION SYSTEMS IN DEVELOPMENT OF
CONTINOUS INTEGRATION SYSTEMS
INTRODUCTION TO CONTINUOUS INTEGRATION
Continuous integration i.e.CI is the merging and integrating all the developer copies
of working to a shared form mainline, generally referred to as a trunk, several times
in a day. A trunk is an unnamed branch of a version that dwells in the file tree of a
code revision system.
Continuous Integration is a good practice that involves all developers to combine
their work on the routine basis to a common code repository. (Turban, Aronson and
Liang, 2005) The main aim of continuous integration is to prevent any problems that
can arise during the integration process and make the integration as smooth as
possible regardless of the use of more and more sophisticated devices, including
servers and networks that the companies of present day are accustomed to use.
This prevention of integration problem was referred to as ‘integration hell’ in the early
versions of XP, an example of it being, the integration of big chunks of data in the
last minute could result in conflicts, the resolution of which would take more time.
(Wang, 2004)
In recent times, Continuous Integration has undergone certain changes and
modifications. Late elaborations have included the use of servers which can be used
to run unit tests periodically or as reported results to the developers. In addition to
the automated tests, Continuous Integration is being used by corporations to as an
application to facilitate quality control, applying it frequently (Wegrzyn-Wolska, 2004). By
running integration and unit tests, test processes like static and dynamic tests,
measure and profile performance, extraction and formatting of source code and
facilitation of manual QA processes take place. Such continuous application is done
so as to test and retest the quality of the software, improve the quality of the software
and to attempt to reduce the time that would be necessary to deliver it. The CI
processes is further used to extend into Continuous sending process, which is a
software engineering development discipline where the software is kept within the

state of principle (Wetprasit, 2003). They could be released towards their users at any
point of time (Wu, Mundluru and Raghavan, 2004). Continuous Delivery is an important
tool which extends into CI and it reduces risks related to deployment, allows
progress tracking and enables fast user feedback.
Relation to Version Control - Trunk
Generally, if developers keep working on the mainline, or the trunk, then it is possible
to improve the mainline into some form of cutting edge workable version of the said
project, however it is also probable that that trunk may be released with as the most
unstable version of the project. As a result, developed generally go on a different
route by splitting the trunk into different branches and then working on the specific
branches and implementing changes on the branches which is later integrated to the
main trunk. Main development is performed in the trunk. Releases are branched for
bug fixes and maintenance releases (Xiang, Huang and Madey, 2003).
Steps of Continuous Integration and Benefits
When bringing about a change in the source code, a developer takes a copy of the
current code base on which the developers chooses to work on. As soon as the
other developer starts to submit the changed codes in the source code repository,
the copy gradually ceases to remain the repository code. However, the longer a code
remains checked out, the more it becomes susceptible to risks due to multiple
conflicts and failures when the developer tries to reintegrate it with the mainline.
Firstly, the developers have to update the code to make it to reflect the necessary
changes. However, the more changes are made, the more would be the work
desired from the work developers to submit their own changes. Finally, the repository
may become completely different from the developers’ baseline, a stage which is
known as ‘merge hell’ or ‘integration hell’ where more time is taken to integrate than
to make original changes (Xu, Huang and Madey, 2003).
For this reason, continuous integration should be taken up so that integration can be
made continuously so that the time taken can be reduced and the efforts taken to
pull a project from ‘integration hell’ could be prevented or minimised. Continuous
Integration could be used to avoid the pitfalls of ‘integration hell’.

Use of Version Control
Version Control is a software configuration management system that is involved in
the management of document changes, computer programs, large websites and
collections of information. Version control can be used to achieve integration control
and automate such a practice. The use of code revision systems is based on the
theory that all artefacts that is required to build the project should be placed in the
repository. Using the practice of code revision systems, the system could rebuild
from a fresh checkout and would not require being additional dependencies.
Moreover, since branching is supported by several tools, its use could be minimised
through code revision system (Yao, 2005). Changes it preferred to be integrated in the
system rather than multiple changes be made into the branches of the project. With
the use of Code revision systems, changes could be made much easily and the
changes could be implemented fast and directly to the root system thus reducing any
amount of conflict that could take place due to the elongated period of time during
which the project was checked out (Yao and Lingras, 2003). As version control helps to
keep the source code intact and as a result this helps in making it easier to make
changes and to make comparisons with the original version, and in that manner
makes it easier for the developers to not lose the branches of the original work but
easily divide it among other developers and integrate the changes frequently in the
original. This helps in both the reduction of time and the improvement in the quality
of the project. Version control is also very useful in being capable enough to help the
developers avoid the pitfalls of ‘integration hell’ by circumventing the problems
completely in the process of integration. Normally, a CI can be referred for tracking
new set of changes from one of the version control system and testing for the system
with each of the change (Yao and Yao, 2003)
Literature Review
Below are all the books or journals that have been referred to during the ongoing
process of this assignment to bring out the overview of the use of code revision
systems for the development of continuous integrations system. There has been

limited research made on this topic but the handful of books has been studied to
bring about the fulfilment of this project. The books that have been referred to are:
1. Continuous Integration, Martin Fowler: Martin Fowler is an esteemed
British software developer who has extensively researched on the concept of
continuous integration and written the aforementioned book about it. From this
book, much could be learned about this novice subject of continuous
integration and how it has developed to become a major part of corporations.
Fowler has also deconstructed the tools necessary for continuous integration
to take place and how it could be made more effective in the long run (Yao,
Raghvan and Wang, 2004). From this literature, it could also be learned the ways
in which code revision systems could be used along with proper develops to
strengthen integration system and make it more effective by the reduction of
work and the ability to circumvent the major pitfalls that could take place due
to ‘Integration Hell’.
2. "Trunk vs. HEAD in Version Control Systems" : Gregory Gary has been
involved in software development for more than twenty years and from his
position, he has given a succinct description of the relationship between trunk
and head and along with it, the relationship of trunk and head with code
revision system and how it affects a project, all of which has been described
in his blog page.
3. Continuous Integration: How to Avoid 'Integration Hell': Sahil Patel is an
engineer and project manager, involved with project management and
services delivery. Having worked on a software development team, his work
on integration hell and continuous integration problems and necessities has
been put in the website to get an overview of the subject. His work has been
published in the DevOps website (Yao, 2003).
4. Continuous Delivery: Reliable Software Releases through Build, Test,
and Deployment Automation Humble: Humble and Farley introduces the
concept of continuous delivery and how it is necessary in the present world.
They also speak about continuous integration and how continuous integration
extends into continuous delivery and the two projects complement each other
in their working, hence helping in the improvement and development of both
individually.

5. Continuous Integration and its Tools: M. Meyer is a expert in
organizational studies and in business administration, and his work has been
published in scholarly articles, especially keeping in view with the need of
code revision system in the development of continuous integration systems
and how better alternatives could be used to improve the code revision
systems and strengthen the power of integration systems to integrate faster
and more efficiently.
APPENDIX: Diagram showing How Continuous Integration required
CODE REVISION SYSTEM:

References
Turban, E., Aronson, J.E., and Liang, T.P. 2005. Decision support systems and intelligent systems,
New Jersey, USA, Pearson Education.
Wang, M, 2004, Design of merchant reputation system: a Web-based purchase decision support
system, in WSS’04, 149-54.
Wegrzyn-Wolska, K. 2004. FIM-metaindexer: a meta-search engine purposebuilt for the French civil
service and statistical classification of the interrogated search engines, in WSS’04, 163-70.
Wetprasit, R. 2003. Developing an intelligent Web-based Thai tutor: some issues in the temporal
expert, in WSS’03, 49-53.
Wu, Z.M., Mundluru, D. and Raghavan, V.V. 2004. Automatically detecting Boolean operations
supported by search engines, towards search engine query language discovery, in WSS’04, 171-78.
Xiang, X., Huang, Y. and Madey, G. 2003. A Web-based collaboratory for supporting environmental
science research, in WSS’03, 29-36.
Xu, J., Huang, Y. and Madey, G. 2003. A research support systems framework for Web data mining, in
WSS’03, 37-41.
Yao, J.T. 2005. Design of Web-based support systems, in Proceedings of the 8th International
Conference on Computer Science and Informatics (CSI), 349-52.
Yao, J.T. and Lingras, P. 2003. Proceedings of 2003 WI/IAT Workshop on Applications, Products and
Services of Web-based Support System (WSS’03), Saint Mary's University, Canada.
Yao, J.T. and Yao, Y.Y. 2003. Web-based information retrieval support systems: building research
tools for scientists in the new information age, Proceedings of the IEEE/WIC International
Conference on Web Intelligence, 570-73.
Yao, J.T., Raghvan, V.V. and Wang, G.Y. 2004. Proceedings of the Second International Workshop on
Web-based Support System (WSS’04), Saint Mary's University, Canada.
Yao, Y.Y. 2003. A framework for Web-based research support systems, in Proceedings of
COMPSAC'03, 601-6.