White Papers

Understanding OPNFV

Issue link: https://read.uberflip.com/i/1344850

Contents of this Issue

Navigation

Page 34 of 144

Understanding OPNFV 34 Steps Involved in DevOps Classic DevOps for internally developed software components is different from DevOps for NFV, where software components are sourced from vendors and open source communities. In this sense, NFV users do not own the development-integration-test cycle of VNFs, instead acting as integrators that compose these third-party VNFs. Another contrast is that classic DevOps assumes homogeneous services, while DevOps for NFV is all about diversity. For these reasons, DevOps for NFV is distinct and different from classic DevOps. Let's take a further look at DevOps for NFV: ● Continuous integration (CI): The idea here is to continuously build and integrate code. When the development is in-house, this could mean that literally every developer commit results in a new integration. However, with third party and open source software, this typically means an integration effort can be kicked off every time there is a release of some external software. With so many components (hypervisor, VIM, MANO, SDN controller, VNFs), you can expect there to come a point in the future where you will see some change just about every week, if not every day! ● Continuous testing: It is not enough to just integrate the software. Even though each piece of software has been tested by itself, the entire stack has to be successfully integrated and tested in a development or staging environment. Naturally, all this testing must be automated. It is not feasible to run manual tests at such a high frequency. ● Continuous delivery (CD): Once the software passes all automated tests, it needs to be deployed into production. Ideally, the new software component co-exists with the older version, and the new component is made available only to a subset of the affected services. These techniques are called canary or blue-green deployments. If the new component holds up in its initial limited production deployment, it's expanded to the rest of the production environment and the old one can be retired. If not, you can simply rollback the changes. In this way, small incremental changes promote stability. They

Articles in this issue

view archives of White Papers - Understanding OPNFV