Traditional and new approaches in software development

The term “blockchain infrastructure” has always caused and continues to cause certain difficulties in its understanding. The reason for this often lies in the fact that we are used to understanding the concept of infrastructure as a set of certain physical means of production, to which software products have recently been added. Thus, we have strictly limited the angle of our perception of this important aspect of the development of blockchain technology. However, just as blockchain technology itself is not only about cryptocurrency, blockchain infrastructure is not only about a set of basic hardware and software.

As soon as a company is faced with the task of developing and implementing blockchain-based projects, then, undoubtedly, one of its first steps on this path will be the creation and maintenance of the very blockchain infrastructure that is absolutely necessary for the successful implementation of the plan. Servers and software, target services that are involved in maintaining the entire system and various software tools – this is the minimum that the infrastructure should cover. Setting up this entire system requires spending money, resources, and time. To be able to minimize these costs, a company just needs to use an outsourcing approach – https://dysnix.com/blog/what-is-blockchain-infrastructure-as-a-service.

Having accepted the obligation to provide BaaS (Blockchain infrastructure as a Service), any provider implements it thanks to professional DevOps developers. Since DevOps is a combination of a variety of approaches and practices aimed at achieving maximum results with minimal losses and costs, the ability of specialists to work in a DevOps environment certainly ensures success. One such DevOps practice is CI/CD, or a practice aimed at software development that is enabled by an automation process.

Before DevOps

Complex processes are always easier to illustrate with examples. Here’s the company whose developers work all day long on an application, adding new features to it and eliminating old bugs. Before DevOps, the algorithm of actions of specialists in such cases looked traditional. The application code was stored locally by the developers, they modified the files on their computer, checked them, and then manually uploaded the files to the server. Having changed the old to the new, the developers were launching the service and hoped that everything would work the first time. If this were not happening, they were beginning to look for an opportunity to urgently correct the situation. At this time the service was idle, and it was bringing losses to the company. The traditional approach also led to other problems. The company’s system administrator received an archive with new versions of files, but very rarely received instructions on how to work with these files. Manual uploading of files led to the risk of increased human errors. The list of problems was also supplemented by all sorts of conflicts that arose due to the fact that different features were made by different specialists and this often led to their inconsistency.

Eventually, it became clear that the traditional approach urgently needed improvement. This improvement was seen in the ability to minimize the influence of the human factor on the process of product development and delivery. It was suggested that human involvement should be limited to the coding phase of the application. Automation of the remaining stages of the process, for example, testing the code and the application itself, launching this application on servers, etc. has become the leitmotif of a new practice – CI/CD. Consequently, the CI/CD approach allows you to build the development process in such a way that you can regularly pour application code with new features and fixes into the project. All subsequent stages of testing and assembly should be carried out automatically, and then the application should be successfully deployed on any infrastructure.

The essence of CI/CD

The acronym CI/CD includes two important components of this approach. The first part – CI (Continuous Integration) is a process in which developers pour their code into the repository often and in small portions. After entering the repository, the code is collected each time and tested for functionality. Constant integration of code into a common base means that at any given time the company has a assembled and tested application that is ready for use in any environment. The repository where the code locked is most often a git-program (not to be confused with the GitHub or Gitlab git server). After the repository the stage of assembling the code into a certain artifact comes, and at this stage you can also check the successful compilation of the code. The artifact is also checked for security and errors using automated tests and statistical analysis of the code is carried out too.

After completing all CI stages, the artifact enters the CD (Continuous Delivery/Deployment) process. During this process, the code is automatically deployed to various environments. We remember that the artifact has already been assembled and tested. So it is being deployed immediately on the servers, moreover, this can be a test environment, pre-production or production one. An important condition is that the deployment process should be as automated as possible to eliminate the risk of human error. The difference between Continuous Delivery and Continuous Deployment is that in the first process the code is released into the production environment after human confirmation, while in the second the pipeline is completely automatic.