Continuous Integration on Cloud Versus on Premise: A review of integration tools

Continuous Integration on Cloud Versus on Premise: A review of integration tools

• INTRODUCTION

1.1 Continuous Integration Overview

Globally, computing technologies are emergent. Businesses are paying close consideration to cloud computing technologies to attain a competitive edge through the deployment of efficient and cost-saving mechanisms in their companies.  Cloud computing brings with it the complexities and paradigms of infrastructure, interface, software development.  To scale down on time, businesses need to market new features of their products. They have turned to modern development practices, including continuous Integration of the cloud infrastructure.  Continuous Integration of the cloud is dependent on business goals.

Continuous Integration commences with software integration. Software integration as part of the development cycle is the practice of linking components of software together to attain a single unified system [1].  Continuous Integration is, therefore, a process of software development, a software engineering concept where developers release their design codes more frequently (continuously) to identify and correct issues earlier as they occur [2]. Continuous Integration is one of the extreme programming (XP) practices that help to reduce efforts for code development. It leads to higher-quality software with delivery results that are predictable [1], [2].

Figure 1:  Architecture pattern [2]

The software market competition is increasing.  Organizations are beginning to give attention to the allocation of resources within their businesses to remain competitive. Companies are investing resources into CI as a practice to attract customers. They are using CI to offer their customers value. [3].

1.2. How Continuous Integration works

Continuous Integration is not a new concept in the field of software engineering. It was recognized in 1991by a software engineer Grady Booch[4], and later adopted by XP with the modification of integrating regularly. In 2015, software configuration was still complex. Vincit, a software development company took the initiative through their Need for Speed (N4S) project to bring tremendous developments and improvements in the features of software giving birth to continuous integration/delivery. Vincit brought out software build and development tools that are automated to support the complexity of the deployment and configurations to the software [5].

Continuous Integration works when developers continually add parts of their system they are working on into a depository.  The parts are automatically tested and built. The developer then receives immediate feedback from the network about the codes newly integrated. The developer is obliged to consider the embedded new codes immediately before they become complicated.  This practice requires each developer to commit to frequently feed in the codes, to fix any broken code quickly, to write the automated tests, and not commit any broken code into the system[1].

Figure 2. Continuous integration delivery [3]

The developers work with the newest codes sent to the system, tested, and built.  When that process fails by any chance, then the developers stop working on their tasks until the failure is fixed. By working this way, they ensure that the new versions are processed within the system with the assistance of the CI tools.

Developers use various tests over time. 1) unit tests that verify individual behavior of functions, 2) integration tests that ensure multiple components run concurrently and correctly to integrate with other services. 3) Acceptance tests that are similar to integration tests but focus on business cases, 4) UI tests that ensure that the system applications are running correctly. To effectively adopt continuous integrations, tests are run every time there is a change detected from every developer through monitoring the repository for the system codes either on the cloud or on-premise.

1.3. Continuous Integration on cloud vs. on-premises

CI tests and builds can run either on the Cloud providers or on-premise systems. Decisions on the deployment are dependent on various factors. Factors range from the CI tools used, the organizational needs, the security of the data, reliability of the providers, and hosting licenses.  These factors vary from one organization to another.  The main factor is the consideration of operational and capital costs [5].

Whether to host CI solutions, on-premise, or on cloud is a never-ending debate. Both options have their cons and pros, but it all builds upon the capital employed. The decisions organizations make on this debate are based on the cons and pros of both, the environmental differences of the cloud and premise (local data center), and the architecture involvement by the developers [6].

• BACKGROUND

Continuous Integration is founded based on software engineering and the constructs of CI, Continuous delivery (CDE), and Continuous Deployment(CD), as depicted in figure 2. Developers cannot implement CD without CI.  Whereas CI has been described and is associated with frequent software building and testing, Continuous delivery (CDE) includes CI and the automated configuration and deployment. On the other hand, continuous deployment (CD) is involved with the corresponding production – it automatically sends software to production once committed. For the sake of this paper, the definitions and how they work together are defined as below.

Continuous Integration (CI)

A subset of Continuous delivery improves software development in terms of quality and speed by building and testing how projects are automated to eradicate errors from developers’ manual environment set up.  This means that software is periodically tested [5] [3].

Continuous Delivery (CDE)

It includes CI and automated end to end. Software testing and delivery are such that they are deployable to any production environment. It ensures that production is readily offering a reduced risk of deployment and increasing chances of delayed feedback. It requires CI practice to function. [5] [3].

Continuous Deployment(CD)

It includes both CI and CDE and automatically deploys software into production environments eradicating the need for manual production [5] [3].

2.2 Literature review on CI integration

Many studies, reviews, and surveys have been conducted on software engineering;- continuous Integration, continuous deployment, and continuous delivery. The studies are on software practices (CI, DCE, and CD) are mainly on approaches, tools, and practices for adoption and implementation. These have gained popular reviews. From 2004 to 2016, [3] have extracted 69 papers on continuous Integration. These numerous studies are a confirmation of the interest and attention that software engineering has attracted. Out of those published papers, 56.5 percent were done in the last three years. Only 32.2 percent of the reviewed papers were continuous integration tools. Between 2001 and 2014, 50 studies were on Continuous Deployment [7].

All these studies, mapping, and reviews reveal the emphasis on the need for researchers to look at the aspect of the framework process, integration tools, and deployability for continuous operations. This paper looks at the Continuous Integration of Cloud versus on-premise to cover the gap.

2.3 Considerations for CI tools on Cloud Versus on Premise

The future of the internet is the cloud. Cloud continues to be embraced as the most convenient and cost-effective way of managing extensive data [8]. After systems have been developed, the CI servers act to give feedback. The CI servers are the determinants of the problem for rectifications. To receive the right fit with the various CI tools, the management is tasked with the burden of determining the organization’s needs. ÇI hostage on cloud software-as-a-service (SaaS) or on-premise (self-hosted) is a priority decision for management [6].

Integration tools fall under various categories; – vendor-supplied on-premise, a third-party on-premise, cloud-delivered, or API web services tools.  These tools determine whether the data processes need to be on-premise or cloud-based platforms depending on the support tools requirements.

CI tools to be deployed

Some edge case features with some CI tools like GitHub, Bitbucket, Heroku is best deployed in the cloud as it requires SaaS solutions. The different models of CI tools are necessary for making the cloud versus on-premise decision [9].

Organization needs

Current and future needs of the organization will require different solutions. Unlike larger organizations with volumes of data processes, small enterprises require solutions that can manage few systems according to their operations. [5].

Data Security:

Organizations that are keen on data security and prevention of data breaches may consider on-premise servers that they can have adequate control over.  SaaS allows organizations to focus on core products to maintain the system infrastructure offering flexibility [10]. There are potential data breaches that need to be observed and control measures taken in conjunction with compliance measures.

Cost

SaaS products (cloud) benefit from a lack of hardware or software management. Cloud is easy to set up using Version Control System tools (GitHub or BitBucket). Businesses initializing and deploying CI on-premises find it time-intensive at the setup stage and CI system initialization. Additionally, apart from the initial capital for hardware and software, authentication, and authorization of users may require management [9] [8].

Flexibility:

An on-premise hostage is not rigid. It can be flexed and extended according to company requirements. They can be customized to suit a particular functionality. For example, Jenkins CI tool that contains over 1000 plugins.  Additionally, on-premise CI tools support larger development platforms and testing frameworks compared to SaaS – cloud. On-premise solutions have fewer limitations on configurations and favor the majority of CI tools [11].

Reliability of the provider

The primary factor when considering CI tools is the availability of the provider of the cloud. The decisions to be made include the ability to change providers should need be. There could arise disagreements; providers could move out of business or shut down [11].

2.3 Review of Continuous Integration tools

For businesses to give their customers value, their systems need to be able to detect errors and correct them quickly and at speed.  This can be achieved through CI tools. CI helps to eradicate errors in the system. When systems are tested, built, and ready for deployment, they are taken through a process. The most common CI tools being used in the market today include; GitLab, Jenkins, AWS CodePipeline, and Bitbucket pipelines, among others. These modern tools are enablers in software engineering deployment due to their speed of delivery and quality.

GitLab On Cloud or On-Premise hosting CI tool

GitLab can be hosted both on-premise and cloud. It offers increased productivity and quality. It acts on pull requests. GitLab is new in the market but has gained popularity and named as a leader in CI [12]. GitLab is easy to use, can be scaled up, integrated, and is innovative.  It uses YAML file to offer DevOps full experience to the engineers -it was created to improve the Githubs experience[13]. Apart from its CI function, it also offers monitoring (Kanban boards and time tracking features) within the applications. GitLab’s one of its management feature is the capability of fast feedback through its pipelines.

Over 1500 companies use GitLab, Alibaba, Trivago, Avocode, Freelancer, Ticketmaster, among others.

Jenkins, On-Prem hosting CI tool

Jenkins is an on-premise hosted CI tool.  It is driven by community updates and uses recent data. Jenkins is documented, can be customized with plugins, and has over 1000 available that allow all manner of functionalities [5] [13].

Jenkins’s flexibility on the distribution of tests and builds makes it popular with most software engineers. It is advantaged in its use on multiple machines. [13]. This feature enables developers to set the CI environment.  It is an open-source – free to use as it is licensed under MIT. Jenkins allows developers to set CI as it is written in java and supports tools like Git, Maven, and Mercurial. Jenkins has over 1 million users.  It has over 147,000 active installations. Facebook, Netflix, LinkedIn, eBay are among the over 2500 companies that use Jenkins for their CI.

AWS CodePipeline, on cloud hosting CI tool

AWS Codepipeline integrated with third party services like GitLab or other custom plugins. It is fully cloud-hosted and integrated with Amazon web services.  It is fast and reliable is a great feature that ensures rapid delivery to users. It has no repository servers, thus delivering software processes using interface, making it easy to deploy applications during customization of its dependencies.

AWS CodePipeline can be customized for specific needs [14]. It is commonly used by companies based in the U.S.  It is suitable for firms having 10000 employees and over and a revenue of 1000 dollars.  Hyatt Hotels Corporation, Asurion LLC, and Smartronix Inc. are among the few companies that use the AWS CodePipeline tool for Continuous Integration.

METHODOLOGY

4.0 CONCLUSION

References

[1]      S. Hamdan and S. Alramouni, “A Quality Framework for Software Continuous Integration,” Procedia Manuf., vol. 3, no. 2015, pp. 2019–2025, 2015, doi: 10.1016/j.promfg.2015.07.249.

[2]      T. Mikkonen, “Elements for a Cloud-Based Development Environment : Online Collaboration, Revision Control, and Continuous Integration,” pp. 14–20, 2012.

[3] M. Shahin, M. Ali, and L. Zhu, “Continuous Integration, Delivery, and Deployment : A Systematic Review on Approaches, Tools, Challenges, and Practices,” 2017.

[4]      G. Booch, Object-Oriented Analysis & Design With Application. Pearson Education, 2006, 2006.

[5]      H. Aleksi, D. Taibi, and K. Syst, “Towards Cloud Native Continuous Delivery : An Industrial Experience Report Towards Cloud Native Continuous Delivery : An Industrial Experience Report,” no. December 2018, doi: 10.1109/UCC-Companion.2018.00074.

[6]      C. Fisher, “Cloud versus On-Premise Computing,” pp. 1991–2006, 2018, doi: 10.4236/ajibm.2018.89133.

[7] P. E. M.VernercMarkkuOivoa, “No TitleContinuous deployment of software-intensive products and services: A systematic mapping study,” J. Syst. Softw., vol. 123, pp. 263–291, 2017.

[8]      M. De Donno, A. Giaretta, N. Dragoni, A. Bucchiarone, and M. Mazzara, “Cyber-Storms Come from Clouds : Security of Cloud Computing in the IoT Era,” pp. 1–30, 2019, doi: 10.3390/fi11060127.

[9]      H. Hai, “SaaS and Integration Best Practices,” 2009.

[10]    J. Sha, A. G. Ebadi, D. Mavaluru, M. Alshehri, O. Alfarraj, and L. Rajabion, “A method for virtual machine migration in cloud computing using a collective behavior-based metaheuristics algorithm,” Concurr. Comput. , vol. 32, no. 2, 2020, doi: 10.1002/cpe.5441.

[11]    P. Jamshidi, C. Pahl, and N. C. Mendonc, “Pattern-based Multi-Cloud Architecture Migration Pattern-based Multi-Cloud Architecture Migration,” no. August 2016, doi: 10.1002/spe.

[12]    The Forrester Wave, “Continuous Integration Tools, Q3 2017 report,” 2017.

[13]    B. Vasilescu, Y. Yu, H. Wang, P. Devanbu, and V. Filkov, “Quality and Productivity Outcomes Relating to Continuous Integration in GitHub.”

[14]    A. S. Delivery, “Practicing Continuous Integration and Continuous Delivery on AWS Accelerating Software Delivery with DevOps,” no. June 2017.