Search

The software development cycle involves testing and deployment stages that can be laborious and time consuming, especially in collaborative projects that involve several developers. Implementing Continuous Integration (CI) and Continuous Delivery (CD) offers a solution to streamline this process. This study presents a case study of the Cloversy.id RESTful API project, highlighting challenges encountered during development and the implementation of a new system using GitHub Actions as the DevOps tool. The research resulted in the adoption of a new system, which replaces the conventional practices previously employed by the Cloversy.id development team. Using flow charts, the study meticulously mapped out the development flow, pinpointing bottlenecks and areas for optimization within the cycle. In particular, the implementation of a CI/CD pipeline resulted in a notable improvement, with a 35% increase in speed for CI and a remarkable 39% enhancement for CD. GitHub Actions played a pivotal role in automating critical tasks, reducing the reliance on manual intervention, and minimizing the dependency on team leaders. The platform's features, including detailed logs and email notifications, empowered team leaders and developers alike to take informed actions swiftly. Furthermore, the study highlights the novelty of integrating CI / CD considering factors such as branching strategy, code review practices, testing methodologies, deployment methods, and infrastructure.

Saat ini setiap organisasi membutuhkan aplikasi untuk memberikan layanan pada pelanggan mereka. Faktanya, 62% organisasi mengatakan aplikasi itu penting untuk bisnis mereka, dan 36% lebih lanjut mengatakan aplikasi memberikan keunggulan kompetitif. Hal ini membuat perusahaan dituntut untuk memberikan inovasi secara cepat demi memberikan kepuasan dan kenyamanan bagi pelanggannya. Untuk merespons tuntutan tersebut, maka organisasi perlu melakukan pengiriman pembaruan aplikasi lebih sering. Dalam proses pengiriman tradisional, setiap proses pengiriman dimulai dengan persyaratan yang ditentukan oleh pelanggan dan berakhir pada produksi. Kelemahan pada pengiriman tradisional adalah lambannya proses pengiriman, dimana proses pengiriman dilakukan secara manual dan berbasis langkah berpotensi menyebabkan titik kegagalan serta kesalahan manusia yang berdampak pada penundaan atau penghentian total sistem. Teknik Countinuous Delivery hadir untuk membantu organisasi mempercepat proses pengiriman aplikasi mereka ke pelanggan. Salah satu perangkat lunak yang dapat digunakan untuk membangun Continuous Delivery dengan zero-downtime adalah Ansible. Berdasarkan hasil pengujian, Ansible berhasil menjaga ketersediaan layanan dengan persentase uptime sebesar 100%. Serta mampu mempercepat waktu deployment sebesar 48%. Dari pengujian beban didapatkan bahwa 1 buah server mampu menangani beban sebesar 2000 user per 5 menit dengan persentase keberhasilan sebesar 99%.

Over the past few decades, the substantial growth in enterprise-data availability and the advancements in Artificial Intelligence (AI) have allowed companies to solve real-world problems using Machine Learning (ML). ML Operations (MLOps) represents an effective strategy for bringing ML models from academic resources to useful tools for solving problems in the corporate world. The current literature on MLOps is still mostly disconnected and sporadic. In this work, we review the existing scientific literature and we propose a taxonomy for clustering research papers on MLOps. In addition, we present methodologies and operations aimed at defining an ML pipeline to simplify the release of ML applications in the industry. The pipeline is based on ten steps: business problem understanding, data acquisition, ML methodology, ML training & testing, continuous integration, continuous delivery, continuous training, continuous monitoring, explainability, and sustainability. The scientific and business interest and the impact of MLOps have grown significantly over the past years: the definition of a clear and standardized methodology for conducting MLOps projects is the main contribution of this paper.

Lack of the procedure of deploying containerized services in microservice systems,the continuous delivery only put executable codes or programs to the production environment.There is no solution for problems of the test version and configuration updates.The microservice system based on container cloud was proposed.Continuous integration for containerized services and the method that supports debugging tests for multi-version of multi-services were designed.Goals of non-stop production and seamless switch between versions were achieved.These services were monitored and managed by an operation and maintenance platform.After production environment verification,the proposed system supports services running without stop and immediate response and satisfies the needs of production.

Lack of the procedure of deploying containerized services in microservice systems,the continuous delivery only put executable codes or programs to the production environment.There is no solution for problems of the test version and configuration updates.The microservice system based on container cloud was proposed.Continuous integration for containerized services and the method that supports debugging tests for multi-version of multi-services were designed.Goals of non-stop production and seamless switch between versions were achieved.These services were monitored and managed by an operation and maintenance platform.After production environment verification,the proposed system supports services running without stop and immediate response and satisfies the needs of production.

Ensuring a production-ready state of the application under development is the imminent feature of the Continuous Delivery (CD) approach. In a blockchain network, nodes communicate and store data in a distributed manner. Each node executes the same business application but operates in a distinct execution environment. The literature lacks research focusing on continuous practices for blockchain and Distributed Ledger Technology (DLT). Specifically, it lacks such works with support for both design and deployment. The author has proposed a solution that takes into account the continuous delivery of a business application to diverse deployment environments in the DLT network. As a result, two continuous delivery pipelines have been implemented using the Jenkins automation server. The first pipeline prepares a business application whereas the second one generates complete node deployment packages. As a result, the framework ensures the deployment package in the actual version of the business application with the node-specific up-to-date version of deployment configuration files. The Smart Contract Design Pattern has been used when building a business application. The modeling aspect of blockchain network installation has required using Unified Modeling Language (UML) and the UML Profile for Distributed Ledger Deployment. The refined model-to-code transformation generates deployment configurations for nodes. Both the business application and deployment configurations are stored in the GitHub repositories. For the sake of verification, tests have been conducted for the electricity consumption and supply management system designed for prosumers of renewable energy.

Continuous practices, i.e., continuous integration, delivery, and deployment, are the software development industry practices that enable organizations to frequently and reliably release new features and products. With the increasing interest in the literature on continuous practices, it is important to systematically review and synthesize the approaches, tools, challenges, and practices reported for adopting and implementing continuous practices. This paper aimed at systematically reviewing the state of the art of continuous practices to classify approaches and tools, identify challenges and practices in this regard, and identify the gaps for future research. We used the systematic literature review method for reviewing the peer-reviewed papers on continuous practices published between 2004 and June 1, 2016. We applied the thematic analysis method for analyzing the data extracted from reviewing 69 papers selected using predefined criteria. We have identified 30 approaches and associated tools, which facilitate the implementation of continuous practices in the following ways: (1) reducing build and test time in continuous integration (CI); (2) increasing visibility and awareness on build and test results in CI; (3) supporting (semi-) automated continuous testing; (4) detecting violations, flaws, and faults in CI; (5) addressing security and scalability issues in deployment pipeline; and (6) improving dependability and reliability of deployment process. We have also determined a list of critical factors, such as testing (effort and time), team awareness and transparency, good design principles, customer, highly skilled and motivated team, application domain, and appropriate infrastructure that should be carefully considered when introducing continuous practices in a given organization. The majority of the reviewed papers were validation (34.7%) and evaluation (36.2%) research types. This paper also reveals that continuous practices have been successfully applied to both greenfield and maintenance projects. Continuous practices have become an important area of software engineering research and practice. While the reported approaches, tools, and practices are addressing a wide range of challenges, there are several challenges and gaps, which require future research work for improving the capturing and reporting of contextual information in the studies reporting different aspects of continuous practices; gaining a deep understanding of how software-intensive systems should be (re-) architected to support continuous practices; and addressing the lack of knowledge and tools for engineering processes of designing and running secure deployment pipelines.

A flaky test is a test which could fail or pass for the same version of a certain software code. In continuous software development environments, flaky tests represent a problem. It is difficult to get an effective and reliable testing pipeline with a set of flaky tests. Also, according to many practitioners, despite the persistence of flaky tests in software development, they have not drawn much attention from the research community. In this paper, we describe how a company faced this issue, and implemented solutions to solve flaky tests for REST web services. The paper concludes proposing a set of key success factors for stopping flaky tests in this type of testing.