CI/CD Process Development for Blockchain Environment Based on

Hyperledger Infrastructure

Maciej Kopa

, Michał Pawlak

, Aneta Poniszewska-Mara

nda

1 a

, Tomasz Krym

1,2

Łukasz Chomatek

1 b

, Joanna Ochelska-Mierzejewska

1 c

, Bo

zena Borowska

1 d

Adam Czy

zewski

and Krzysztof Stepie

Institute of Information Technology, Lodz University of Technology, Ł

z, Poland

kodegenix, Ł

z, Poland

Keywords:

Blockchain, DevOps, Continuous Integration and Continuous Delivery, Hyperledger Fabric, Chaincode.

Abstract:

Blockchain is a promising and quickly developing technology with the potential to disrupt numerous indus-

tries. Hyperledger Fabric, an open-source blockchain platform can be used in conjunction with continuous

integration and continuous delivery (CI/CD) pipelines. The paper presents the well-organized blockchain de-

velopment environment for software engineers, its conﬁguration and use in the form of CI/CD pipeline and its

integration with Hyperledger Fabric. A case study illustrates the implementation of these technologies in real-

world scenario to provide a comprehensive understanding of how Hyperledger Fabric and CI/CD pipelines

can be leveraged to improve the efﬁciency of private blockchain network development process.

1 INTRODUCTION

Blockchain is a promising and quickly developing

technology with the potential to disrupt numerous in-

dustries. Due to the blockchain’s decentralized char-

acter, it is difﬁcult for a single person to edit or tamper

with the data kept on the ledger without the agreement

of the other members. The potential of blockchain

technology to facilitate trust and transparency be-

tween parties without the need for a central authority

or intermediary is one of its primary advantages. As

a result, it is a great technology for use cases where

conﬁdence is crucial. Despite the fact that blockchain

technology delivers tremendous trust and security so-

lutions, its high learning curve makes it challenging

for developers to leverage its potential fully.

Blockchain technology is a complex and broad

topic with various platforms and solutions, which can

make it difﬁcult for developers to initiate and main-

tain effective development. To build complicated net-

works and ecosystems of smart contracts, decentral-

https://orcid.org/0000-0001-7596-0813

https://orcid.org/0000-0002-7651-6877

https://orcid.org/0000-0002-9295-3962

https://orcid.org/0000-0001-7640-5782

ized storage, and consensus protocols, blockchain ap-

plications require developers with extensive knowl-

edge and experience. In addition, developers typ-

ically lack a comprehensive understanding of the

blockchain’s architecture and conﬁguration, necessi-

tating the inclusion of blockchain administrators and

operators in every project. As a consequence, it is im-

perative that a solution must be implemented in order

to overcome the challenges that blockchain develop-

ers face during the early stages of the development

process.

The paper examines various aspects of blockchain

technology, DevOps, and Hyperledger Fabric to

present how to design and build an efﬁcient, collabo-

rative, and robust Continuous Integration/Continuous

Delivery (CI/CD) blockchain development environ-

ment based on Hyperledger Fabric infrastructure for

experimenting, testing, and delivering networks, as

well as interacting with the network and implement-

ing business logic. It discusses the software engi-

neering and DevOps problems related to the Hyper-

ledger Fabric project concerning the CI/CD environ-

ment. This comprises the study and design of pri-

vate Blockchain with Hyperledger Fabric and other

tools, its setup and maintenance, chaincode creation

and testing, and the building of CI/CD pipelines.

580

Kopa, M., Pawlak, M., Poniszewska-MaraÅ

Dda, A., Krym, T., Chomatek, Å ˛A., Ochelska-Mierzejewska, J., Borowska, B., CzyÅijewski, A. and StepieÅ

D, K.

CI/CD Process Development for Blockchain Environment Based on Hyperledger Infrastructure.

DOI: 10.5220/0012129700003538

In Proceedings of the 18th International Conference on Software Technologies (ICSOFT 2023), pages 580-587

ISBN: 978-989-758-665-1; ISSN: 2184-2833

 2023 by SCITEPRESS – Science and Technology Publications, Lda. Under CC license (CC BY-NC-ND 4.0)

2 BLOCKCHAIN TECHNOLOGY

AND HYPERLEDGER FABRIC

Blockchain is a technology that incorporates a shared

ledger concept for a number of application domains.

It can be used in almost any scenario that requires

a decentralized, reliable, trustworthy, and automated

system for data storage and business logic (IBM,

2021). Blockchain can be deﬁned as a shared, im-

mutable registry that accelerates the recording of

transactions and tracking of material assets across an

enterprise network. Assets can be material (e.g. car,

land) or immaterial (e.g. patent, opinion) (Bitcoin,

2021; Dogecoin, 2021).

The core concept behind blockchain is Distributed

Ledger Technology (DLT) – decentralized registry of

data that each participant collaborates to maintain (Li

and Kassem, 2021). Thanks to data being replicated

across the network participants, each of them holds

the same view of truth. DLT can occur in three dif-

ferent types: permissionless (public), permissioned

(private) and hybrid. The hybrid solution strives to

beneﬁt from both public and private blockchains. It

denotes controlled access while maintaining the con-

dition of being open – some processes are kept private

while others are public.

Immutable records are one of the characteristics

of blockchain which builds trust and transparency in

the network. Blockchain network can be viewed as

peer-to-peer communication between its participants,

but everything that resulted from the communication

is recorded in a public ledger and accessible to all.

The information recorded in the blockchain is guar-

anteed to be immutable thanks to many cryptographic

techniques (Zhang et al., 2020), in such a system it is

easy to track and prove the ownership of an asset. It

also protects from changing and tampering with data.

Smart contracts are a set of rules that enables a

bunch of ledger functions, e.g. transactions, query-

ing, etc. They deﬁne business logic that generates

new facts that are added to the ledger. They are writ-

ten by administrators, agreed upon by participants,

and saved on the ledger for automatic execution by

clients. Each transaction in the blockchain network

must be validated. Consensus mechanisms accumu-

late rules and govern how the validation is done. It

should be understood as a full-circle veriﬁcation that

needs a number of steps to pass the check and ap-

prove the correctness of a block. There exist numer-

ous types of these mechanisms, e.g. Proof of work

in Bitcoin, Proof of stake in Ethereum, or highly cus-

tomizable consensus policy from Hyperledger Fabric.

Hyperledger is an open-source platform for build-

ing and deploying blockchain solutions. It provides

distributed ledger software, libraries, and tools to

help build almost any case-speciﬁc blockchain (Hy-

perledger, 2020a). Hyperledger Fabric is the most

popular and followed GitHub project hosted by the

Linux Foundation (GitHub, 2020). Fabric is intended

to serve as a foundation for the development of pri-

vate blockchain solutions (Gaur et al., 2018). It is the

ﬁrst blockchain architecture that is completely ﬂex-

ible for hosting any distributed applications (IBM,

2018). It offers a unique approach to consensus mech-

anism that provides the desired scalability and privacy

with channels and private data (Team, 2020). Fabric

supports smart contracts in, popular modern program-

ming languages, Go, Java, and JavaScript, its gover-

nance, and versioning (Team, 2020). Fabric, in con-

trast to other blockchains, is cryptocurrency agnostic

(IBM, 2018). Because of a ﬂexible choice of plug-

gable databases – LevelDB or CouchDB – the data

stored on the ledger is immutable and easily quarri-

able by peers. The assets can represent anything of

value, making them versatile and adaptable to any

use case. Identities in Fabric are managed by Mem-

bership Service Providers (MSP) and Certiﬁcate Au-

thorities (CA). This makes Fabric a reliable system

with a security architecture based on X.509 certiﬁ-

cates and Public Key Infrastructure (PKI) (Gaur et al.,

2018) and certiﬁcate attributes (Cooper et al., 2008).

The current version of X.509 is RFC 5280 (Cooper

et al., 2008) and is distributed by Certiﬁcate Authori-

ties (CA), for example, Symantec (DigiCert).

3 HYPERLEDGER CHAINCODE

DEVELOPMENT PIPELINES

The Hyperledger network is reliable, secure and pro-

vides a single source of truth, therefore, it can serve

as a core of many systems. The goal of the project

was to design and develop a system that can collect,

store with blockchain and evaluate with Artiﬁcial In-

telligence user opinions about products purchased. It

is split into three separate modules that must swiftly

interact to achieve desired outcomes (Fig. 1).

Figure 1: Modules of developed system.

The ﬁrst module focuses on collecting and orga-

nizing the data from various sources. The source of

the opinions depends on the actual needs, therefore

the system should be ﬂexible and easily adaptable

to allow such multiple choices. The ﬁrst and major

CI/CD Process Development for Blockchain Environment Based on Hyperledger Infrastructure

581

source of the data is going to be Opinion Collector

(OC) application which is a custom-made web ser-

vice with functions such as listing, collecting, and

sending opinions further to the core of the system

which is the blockchain module. The goal is to have a

standalone service that will always and independently

collect more and more data from users. The OC

will also manage its own relational database, which

will be additionally powered with the data previously

stored by OC and other network participants inside

the blockchain.

The next module, namely Artiﬁcial Intelligence

(AI) aims to retrieve the data from the blockchain,

analyse it and reﬂect the decision inside the

blockchain. This module is responsible also for au-

tomatically training the newer and newer versions of

the model and persisting it on its own. The model

will never be exposed to the blockchain, but only be

used for evaluations of new data on demand. The re-

sults, however, will be posted back in the ledger inside

a different channel than the one with data providers.

This will provide versatility and allow for the further

expenditure of the network by adding new, interested

cooperation companies, consequently providing more

and more beneﬁts from the system.

The core and fundament of the system is

blockchain module (BC) built with Hyperledger Fab-

ric. It merges every module into one reliable and fully

functional system. The development process is driven

by the needs of other modules as well as any secu-

rity and reliability concerns. The network provides a

place where invited organizations can interact in or-

der to produce the desired value. The initial network

consists of 3 organizations (other 2 modules and or-

dering service) and 1 channel, but with considerable

space for expansion shortly. The network utilizes de-

signed smart contracts for any operational logic in-

volved and provides APIs for participants for safe in-

teractions from outside the network.

Overall, this project aims to provide a compre-

hensive solution for collecting, analysing and utiliz-

ing data to allow more efﬁcient and reliable decision-

making. The opinions will originate from differ-

ent sources and be analysed by an artiﬁcial intelli-

gence model trained with substituted data. Every-

thing of value will be placed inside the ledgers of the

blockchain module and accessible for invited orga-

nizations that will participate in the maintenance of

the network with an exchange of the new data or out-

comes of their actions. This paper focuses on the BC

module conﬁguration and prototype development. It

assumes that the OC and AI modules are independent,

thus are out of the scope of this paper. Nevertheless,

some decisions during the BC module development

are taken with explicit consideration for these mod-

ules, thus effectively inﬂuencing the shape of the net-

work and development environment.

Hyperledger Fabric is highly modular and conﬁg-

urable, allowing developers to choose the components

that are needed for a speciﬁc use case, and to easily

add or remove functionality as required. This ﬂexi-

bility makes it easy to create solutions that meet the

speciﬁc needs of different organizations. Privacy, per-

formance, and scalability are key advantages of us-

ing Hyperledger Fabric, allowing organizations to re-

liably manage large volumes of transactions without

any additional costs involved. That is why Hyper-

ledger Fabric is a better choice for this case study than

other blockchain platforms.

3.1 Architecture of Chaincode

It must be determined whether the network will be

a test or production network. This decision is cru-

cial because it indicates what actions must be taken

and what the beneﬁts of the system will be. The pur-

pose of presented works was to prepare a develop-

ment environment so that the network is built around

the test network requirements. The test network pro-

vides advantages such as increased performance dur-

ing chaincode development and allows the developer

to focus on the solution and test cases rather than

the network’s technical aspects. The test network re-

places some of its critical components with elements

that operate on the same principle but have a simpler

architecture. For example, the test network would not

use any valid Certiﬁcate Authorities, but all crypto-

graphic materials would be generated and stored lo-

cally using the cryptogen utility tool. Cryptogen tool

is provided as a means of preconﬁguring a network

for testing purposes(Hyperledger, 2020b). As a re-

sult, all endorsements are automated, and proposals

are generated faster than in a production network.

Furthermore, it is likely to use a deprecated solo or-

dering service or raft ordering service with only one

node, which boosts efﬁciency and saves resources but

leaves it open to failures and brownouts. This exam-

ple clearly demonstrates why a test network is inse-

cure and should not be used in a production environ-

ment, but works ﬂawlessly for testing both locally and

during pipeline execution.

Reliable ordering service is a top priority for the

production network. However, this component of the

test network can be simpliﬁed. This can be done by

using an algorithm for an ordering service that re-

quires a minimum number of working peers to per-

form its duty. There are two options that can be con-

sidered good choices for a development environment:

ICSOFT 2023 - 18th International Conference on Software Technologies

582

solo or raft. Solo, as the name suggests, is a peer-

to-peer, standalone ordering service. It is intended to

function as a fully functional ordering service for Hy-

perledger Fabric, but it is regarded as unreliable and

vulnerable to any potential data-tempering actions.

Raft ordering service, on the other hand, is one of

the ordering service implementations in Hyperledger

Fabric that provides the most beneﬁts. It uses the Raft

consensus algorithm to ensure that all the ordering

nodes in the network agree on the order of transac-

tions. This ordering service provides a more fault-

tolerant and decentralized way to order transactions

compared to other ordering services such as Solo and

Kafka. This guarantees that all peers in the network

have the same version of the ledger and can quickly

verify any transactions that are made. On top of that,

Raft is the only recommended algorithm, while Solo

and Kafka are both deprecated in Fabric version 2.5,

although they can still be used. In this project, the

ordering nodes (Raft) will be supplied by an adminis-

trative organization without the right to transact.

Since AI and OC modules perform different duties

in the system, they also demand different transactions

from the network. Developers must therefore take this

into account when designing transactions and assets.

This can be done in three different programming lan-

guages: JavaScript, Java, and Golang. As shown in

ﬁgures 2 and 3, there are four different assets with

four smart contracts. Each smart contract is respon-

sible for the management of its assets stored in the

ledger. All smart contracts are designed to be installed

and invoked simultaneously on the same channel and

accessible to both organizations. This decision is due

to the fact that some of the contracts rely on each

other, and storing them on different channels would

unnecessarily slow down the transactions.

The assets are designed to optimize their useful-

ness in terms of business logic, as well as query capa-

bilities. Two assets, namely Product and Review, are

the core assets of the system. The other two assets are

inextricably linked to the main assets. Speciﬁcally,

products have critical relationships with product cate-

gories and reviews have critical relationships with re-

view grades. While features like product categories

and review ratings could be built into the system’s

foundational components, their design is ultimately

informed by the need to accommodate users’ require-

ments while also preserving the system’s high level of

maintainability and performance. A dynamic, rather

than static, the addition of product categories is re-

quired. Review grades, on the other hand, will change

often, and to keep these changes small, in terms of ad-

ditional bytes stored on the ledger, it was decided to

keep them separated from reviews that are very un-

likely to change ever.

The designed blockchin network is presented in

ﬁgure 4. it contains one channel and ordering service,

with one node dedicated to this channel (Raft consen-

sus algorithm). Two organizations are connected to

the channel via peers. Each of them has a peer, its own

ledger and has installed smart contracts on it. Orga-

nizations invoke transactions via a dedicated API for

each organization and communicate with each other

on the channel via peers.

3.2 CI/CD Pipelines Structure

CI/CD pipelines can greatly increase the efﬁciency

of developers during Hyperledger Fabric network de-

velopment by providing a streamlined and automated

workﬂow for building, testing, and deploying code

(Fig. 5). The pipelines are constructed with main

and child pipelines. Parent pipeline triggers given

child pipeline only on code changes regarding this

chaincode. The child pipeline contains jobs such as

building and various testing. If all chaincodes suc-

ceed, the parent pipeline triggers the next stage where

jobs build and turn on the network, install all chain-

codes, and ﬁre integration tests against this network.

Lastly, the pipeline delivers tested containers to the

docker repository. This can help reduce errors and

improve the overall quality of the codebase. In the

end, this will speed up the development process and

make it possible to add new features and functions

more quickly. Moreover, the workﬂow allows for efﬁ-

cient deployment of smart contracts on a Hyperledger

Fabric network.

Continuous Integration (CI) pipelines can be com-

bined with automated testing tools, which can run a

suite of tests on the codebase each time a change is

made. That is why every change to the codebase will

trigger a pipeline dedicated to the given chaincode

where the change was detected. Additionally, this

process of separation will also optimize the pipeline

and shorten its duration. The pipeline will cover code

linting and unit testing with the Gradle plugin, sce-

nario testing with the Cucumber tool from Smartbear,

and ﬁnally, integration testing against a real network

with a simple bash script that utilizes curl and grep

commands.

With CI/CD in place, developers can easily deploy

new versions of smart contracts to a test network, test

them, and ensure they are working as expected, before

deploying them to a live network. It will also ensure

that the entire work is stable and free of errors. The

test network will be created with the use of conﬁgu-

ration ﬁles and the Docker compose tool every time a

pipeline is triggered. As a result, the pipeline job will

CI/CD Process Development for Blockchain Environment Based on Hyperledger Infrastructure

583

Figure 2: Smart Contract classes for Chaincodes.

Figure 3: Assets structure for Chaincodes: ProductCategory, ReviewGrade, Product and Review.

result in a bunch of dependent containers. If this pro-

cess succeeds, the integration tests will allow ensur-

ing the quality of the product. Next, containers will

be sent to the repository, where the operations team

can take over and proceed with the deployment of the

network. This step ﬁnalizes the process of CD.

4 DEVELOPMENT

ENVIRONMENT

Process of building the network and end-to-end

pipelines for chaincode development, testing and de-

livery are presented below.

4.1 Network

The blockchain network was based on Hyperledger

Fabric with the use of external tool called Fablo that

simpliﬁes the process of creating and deploying Hy-

perledger Fabric networks locally. The tool provides

a set of commands to automate the creation and de-

ployment of blockchain networks.

The ﬁrst step to create Hypereldger Fabric net-

work with Fablo is to create an empty project and ex-

ecute fablo init rest command. It will create a basic

fablo-conﬁg.json ﬁle and enable Fablo REST tool to

be useful later. The conﬁguration ﬁle contains all in-

formation about the network, Fabric version, organi-

zations, channels, chaincodes. The Fablo conﬁgura-

tion ﬁle speciﬁes OC, AI, and Orderer organizations,

pro-rev-channel and its participants, and Fabric ver-

sion that supports TLS communication. In addition,

it speciﬁes the Raft algorithm and number of nodes

for Orderer. The network created by Fablo can be de-

ployed elsewhere. It can be achieved by running fa-

blo generate and changing both fabric-docker.sh and

docker-compose.yaml ﬁles.

ICSOFT 2023 - 18th International Conference on Software Technologies

584

Figure 4: Initial network architecture reference.

Figure 5: CI/CD pipelines workﬂow structure with steps.

4.2 Chaincodes

While the network is already up and running, it lacks

the business logic to perform its duties such as e.g.

storing product reviews in our developing system.

The implementation of exemplary assets as Prod-

uct, ProductCategory, Review, and ReviewGrade was

done using Java language and Gradle tool, used for

building, testing, and deploying the chaincodes.

The setup of a project (chaincode) requiring the

creation of a new empty Gradle (version 7.0.2) project

and the modiﬁcation of fablo-conﬁg.json by adding

the chaincode deﬁnitions that Fablo will attempt to

install and initiate in the speciﬁed channel. Fablo will

also acquire the deﬁnitions of all chaincodes. The en-

dorsement key speciﬁes the policy that needs to be

meet for a given chaincode. Also, the IDE should

have access to JDK 11. The build.gradle ﬁle must

then be conﬁgured by adding two repositories and

plugins. One plugin allows generating fat/uber JAR

ﬁles and other is for code linting. The Gradle shadow-

Jar task must be conﬁgured to generate the JARs. The

same goes for Checkstyle plugin. Also, the neces-

sary dependencies must be considered. It includes li-

braries such as Genson that allow objects to be parsed

to JSON in a consistent manner, as well as a Java im-

plementation of Hyperledger Fabric chaincode inter-

face SDK.

The next step is process of creating assets, from

the deﬁnition of asset’s attributes to implementation

of smart contracts (chaincode) that will handle the as-

set’s transactions and operations. This task can be dis-

cussed in detail for example for Product assets. It re-

quires deﬁning a new public class Product and anno-

tating it with DataType. Inside the class object, there

should be declarations of class variables according to

ﬁgure 3 and with another annotation Property that can

be used to deﬁne a schema for String or min/max val-

ues for Integer. The class must also offer getters and

a constructor.

The smart contract includes functions that repre-

sent transactions for blockchain network (Fig. 2).

The ProductContract class must implement Contract-

Interface and have Contract and Default annotations.

Following that, each transactional function must have

an appropriate Transaction annotation with intent de-

ﬁned. The type of transaction is determined by the

CI/CD Process Development for Blockchain Environment Based on Hyperledger Infrastructure

585

intent, such as SUBMIT, which changes the ledger,

or EVALUATE, which only reads it. A Context must

always be passed in addition to any function param-

eters. createProduct() is a simple function that takes

the Context, and name, category, content to prepare

a Product with generated UUID for productID. Addi-

tionally, it checks if it does not already exist. Follow-

ing that, it serializes the Product class with Genson

and, thanks to Context, obtains the ChaincodeStub to

inserts a new state into it.

4.3 CI/CD Pipelines

The next step is to set up CI/CD pipelines using Git-

Lab CI/CD services for previously created fully func-

tional blockchain for one of the main puroposes of our

system, so the user opinion storage. GitLab CI/CD is

a built-in feature of GitLab that allows the automated

testing, building, and deployment of code changes.

The pipelines is created from parent and children

pipelines, this means they contain ﬁve .gitlab-ci.yml

ﬁles, one for each chaincode and one core pipeline.

These ﬁles deﬁne all stages and jobs, and enforce au-

tomation and performance rules.

All child pipelines dedicated to integrating chain-

codes look in the same way as shown in ﬁgure 5. Each

child pipeline contains two stages and two jobs. The

ﬁrst stage is the build stage with a dedicated job. It

simply compiles the code with Gradle and for opti-

mization purposes, the results get cached. This job

must succeed in order for the next job to start. The

next stage and job is more complex and offers three

beneﬁts: code listing, unit testing and scenario test-

ing. Everything is managed by a Gradle tool, JU-

nit, Checkstyle, and Cucumber plugins. Before the

script starts, it sets up the Gradle user home direc-

tory and applies it to the current CLI. This step is

required for all Gradle-related jobs inside a GitLab

CI. When it is done, the core script begin with gradle

check command, which implies three functions. First

one lints the codebase of chaincode according to the

given checkstyle ﬁle. Next one proceeds with veri-

fying the unit tests, and last one triggers all scenario

tests with Cucumber runner. It is worth noting that if

Gradle check command fails on any step it will not

proceed further. Therefore, it might be a good idea

to split the Gradle tasks into three separate jobs. This

will also decrease the duration time of a pipeline be-

cause these jobs could run simultaneously. However,

this GitLab pipeline setup uses a single runner and

running linting process automatically runs any other

test cases, therefore the results would not be better for

this exact setup. When children pipelines were exe-

cuted for every chaincode that was changed and if all

succeed, the parent pipeline continues with the next

stages.

The main pipeline .gitlab-ci.yml ﬁle is in project

root folder, next to fablo-conﬁg.json. The main

pipeline (Fig. 5) must include triggers for child

pipelines, build and conﬁgure a network for tests, and

deliver containers to storage. As a result, the work-

ﬂow has three stages in the following order: trig-

gers, test and deliver. The ﬁrst stage includes a job

for each chaincode – it has deﬁned conditions known

as rules or only that, when met, the main pipeline

will include and execute the speciﬁed child pipeline.

The only deﬁned rule for this job is changes. As a

result, it only occurs when GitLab detects a differ-

ence between this and the previous commit, in order

to save time and resources. After all child pipelines

have passed and the triggers stage has ﬁnished, it is

time for the next step in the workﬂow, which is the

test stage. It involves creating the actual network, in-

stalling the previously tested chaincodes and testing

it against a real network. The job requires an im-

age with docker and docker-compose already conﬁg-

ured. Nonetheless, the environment requires the deﬁ-

nition of a few variables that will be selected automat-

ically by Docker and utilized during execution. This

includes DOCKER HOST, DOCKER DRIVER, and

DOCKER TLS CERTDIR. DOCKER HOST is an

environment variable that is used to specify the URL

of Docker daemon. It ensures that Docker client will

automatically connect correctly to running Docker

daemon. DOCKER DRIVER conﬁguration option is

used to specify the storage driver that should be used

by Docker. The overlay2 storage driver is a mod-

ern and recommended storage driver that provides

better performance and stability in comparison to its

predecessors. DOCKER TLS CERTDIR is an envi-

ronment variable that is used to specify the directory

where the Transport Layer Security (TLS) certiﬁcates

for Docker daemon are located. When it is set to an

empty string, it also requires turning the TLS com-

munication off. It can be achieved by invoking the

command –tls = false on creation.

Before the script can execute, it must download

some basic dependencies, because the image comes

as small as possible. Alpine Linux has its own pack-

age manager, apk, for installing and managing soft-

ware packages. The main script pulls the Fablo tool

and starts the network using fablo-conﬁg.json. The

chaincodes are already deﬁned in the ﬁle and is in-

stalled after the network is up and running. Next,

the job pulls another tool, which is the Api-test bash

script and runs all test cases against Fablo REST API.

To implement CD, the project ﬁrst established a

strong testing infrastructure and Continuous Integra-

ICSOFT 2023 - 18th International Conference on Software Technologies

586

tion. This includes automated unit tests, integration

tests and scenario tests to ensure that new code

changes will not introduce bugs or break existing

functions. The ﬁnal step in the workﬂow (Fig. 5)

is the delivery of product to a destination where

the operators team can take over and focus on its

deployment. The delivery stage is located in the main

pipeline and requires the previous stage to ﬁnish suc-

cessfully. Regarding all necessities such as services,

variables, and tools, the delivery stage is quite com-

parable to the preceding one. As the network is not

intended to be started within this job, only the docker

images and docker-compose.yml ﬁle need to be pre-

pared. It is possible with fablo generate command. It

creates fablo-target folder containing all required ﬁles

within the root folder of the project. Next, the job

uses a simple bash script that tags generated docker

images with the tag following the GitLab schema

¡registry URL¿/¡namespace¿/¡project¿/¡image¿.

For example, a container with the name

ca.orderer.example.com is tagged with the com-

mand docker tag ca.orderer.example.com reg-

istry/salus/blockchain/ca.orderer.example.com:latest.

The last command docker compose push sends all

images to the speciﬁed registry.

5 CONCLUSIONS

The paper presented proposal on how a blockchain

development environment should look like and its im-

plementation with use of Hyperledger Fabric, Fablo,

Docker, Java with Gradle, and GitLab. Fablo and

Docker were used to conﬁgure and manage the net-

work initially. It consists of three organizations, one

channel, and a policy requiring at least ﬁfty percent of

participants to validate. Each organization has a sin-

gle peer which fulﬁls all peer responsibilities. Peers

are responsible for managing smart contracts, assets,

hosting ledger copies, endorsement, validation, and

transaction invocation. This rule applies to all organi-

zations with the exception of ordering service that was

developed using the Raft consensus algorithm and a

single node to reduce resource consumption and ac-

celerate the process.

Using the Gradle automation tool, four smart con-

tracts and four assets were developed in the Java lan-

guage. In addition, the chaincode development pro-

cess entailed editing the Fablo conﬁguration ﬁle, ap-

plying code linting with Checkstyle, writing unit tests

with JUnit, preparing scenario tests with Cucumber,

and creating integration test cases with Postman and

Api-test script. In order to automate the develop-

ment environment, the CI/CD pipelines were conﬁg-

ured using GitLab’s CI/CD service. The introduced

workﬂow consists of two interdependent components.

First, the child pipelines that are responsible for au-

tomating the integration of each chaincode only when

changes occur. Each includes a build task, linting,

unit testing, and scenario testing. The main pipeline

proposed a method for triggering the child pipelines,

created a network within the runner, tested the net-

work using a suite of integration tests, and then deliv-

ered everything to the GitLab registry. Total conﬁgu-

ration is limited to ﬁve ﬁles, making the management

of pipelines relatively simple.

ACKNOWLEDGEMENTS

The presented work was supported under the grant of

Polish National Center of Research and Development,

Project No. INFOSTRATEG-III/0004/2021-00, ”Ar-

tiﬁcial Intelligence and Blockchain for the product

quality and safety control system (SALUS)”.

REFERENCES

Bitcoin (2021). Bitcoin technology. Online,

https://bitcoin.org/.

Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley,

R., and Polk, W. (2008). Internet X.509 Public Key

Infrastructure Certiﬁcate and Certiﬁcate Revocation

List (CRL) Proﬁle.

Dogecoin (2021). Dogecoin technology. Online.

Gaur, N., Desrosiers, L., Ramakrishna, V., Novotny, P.,

Baset, D., and O’Dowd, A. (2018). Hands-On

Blockchain with Hyperledger. Packt Publishing.

GitHub (2020). Hyperledger Fabric – GitHub repository.

Online, https://github.com/hyperledger/fabric.

Hyperledger (2020a). Hyperledger documentation. Online,

https://www.hyperledger.org/.

Hyperledger (2020b). Hyperledger Fabric Doc-

umentation. Online, https://hyperledger-

fabric.readthedocs.io/en/release-2.5/.

IBM (2018). Hyperledger Fabric: A Distributed Oper-

ating System for Permissioned Blockchains. Online,

https://arxiv.org/pdf/1801.10228.pdf.

IBM (2021). What is blockchain technology? Online,

https://www.ibm.com/topics/what-is-blockchain.

Li, J. and Kassem, M. (2021). Applications of distributed

ledger technology (dlt) and blockchain-enabled smart

contracts in construction.

Team, H. (2020). Hyperledger Fabric Whitepaper. Online,

https://www.hyperledger.org/wpcontent/.

Zhang, R., Xue, R., and Liu, L. (2020). Security and privacy

on blockchain.

CI/CD Process Development for Blockchain Environment Based on Hyperledger Infrastructure

587