# From DevOps to MLOps: Overview and Application to Electricity Market Forecasting
## 3 An Overview of DevOps and MLOps
### DevOps
#### 3.1.2 DevOps Pipeline  
In practice, some of the DevOps components mentioned above are combined to form a sequence of operations called a pipeline. There is no single generalized pipeline structure [80; 112]. Every pipeline is unique, and the pipeline structure depends on the nature of the application and the implementation technology. In DevOps, the following common pipeline components can be found [53; 54; 58; 77; 84]:  
* Continuous Integration (CI);
* Continuous Delivery (CD);
* Continuous Deployment;
* Continuous Monitoring. These pipelines include DevOps components mentioned in the previous section. Most of the DevOps implementations consider CI and CD as the core components. Continuous integration is the practice of integrating code changes from multiple developers into a single source via automation [77]. The important practice of CI is that all developers commit the code frequently to the main or trunk branch [113] mentioned in Section 3.1, subsection 'Plan' After the commitment, the code building is performed as explained in Section 3.1, subsection 'Build'. As soon as the build succeeds, the unit test cases are run as explained in Section 3.1, subsection 'Test'. Primarily, CI uses SCM (Software Configuration Management) tools such as Git, as explained in Section 3.1, subsection 'Code', to merge the code changes into SCM for code versioning. CI also performs automated code quality tests, syntax style reviews, and code validation [114]. Since many developers integrate the code, the following issues may occur:* **Code or merge conflicts:** This is the state when SCM is unable to resolve the difference in code between two commits automatically. Until the merge conflict is resolved, the SCM will usually not allow the code to be merged. Usually, merge conflicts happen if the changes are inconsistent when merging changes from two branches [115]. * **Dead code:** Dead code is a block of code never reached by the execution flow [116]. Dead code can be introduced at any step in the programming as part of a code merge. For instance, consider two feature branches: Feature A and Feature B. Feature A's developers might have considered some exceptions from Feature B and created code blocks to handle that. However, if this exception never happens or some logic in the Feature B branch changes, this exception block will never be executed [117,118]. * **Code overwrites:** As the software evolves, there is a high possibility that the old code needs to be updated to meet the ever-changing requirements. Nevertheless, this might also affect the old features, resulting in code breaks after merging. One of the primary benefits of CI is that it saves time during the development cycle by identifying and addressing conflicts early [119]. The first step in avoiding the abovementioned issues is to set up an automated testing pipeline [80,120]. In a CI testing pipeline, the code should be built successfully with no code conflicts before the tests are run. The CI pipeline tests vary depending on the nature of the application. To get an early warning of the possible issues, it is suggested to run this CI pipeline for every branch of the SCM and not only on the main or trunk branches. The basic CI pipeline is ready once the SCM and an automated unit testing framework are ready. The following are some of the critical points to keep in mind while implementing CI:  
* Unit tests are fast and cost less in terms of code execution time as they check a smaller block of code [121]. * UI tests are slower and more complex to run, more complex to set up, and might also have high costs in terms of execution time and resource usage. Furthermore, a mobile development environment with multiple emulators and environments might add more complexity. Hence, UI tests should be selected more carefully and run less frequently than the unit tests [103,122]. * Running these tests automatically for every code commit is preferred, but doing this on a development or feature branch might be costlier than manual testing [123].