White Papers

Understanding OPNFV

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

Contents of this Issue

Navigation

Page 94 of 144

Understanding OPNFV 94 1. A contributor clones git master to a local repo. 2. The contributor makes changes, adds code or fixes bugs and performs local unit testing. 3. The contributor submits the patch for review. 4. The patch is verified using a Jenkins CI verif y job. 5. Reviewers can inspect the patch and the CI result; the patch may be accepted, rejected or sent back for revisions. 6. If the patch is accepted, one of the committers submits the patch to Git trunk, which triggers a Jenkins post- mer ge job. 7. Jenkins jobs also create local artifacts, such as Docker containers for test tooling. 8. Finally, Jenkins jobs run a variety of tests on a daily, weekly, or non-recurring basis. These tests run on OPNFV software deployed using code built from the Git trunk, upstream artifact repositories (such as OpenStack, ODL etc.) and local artifact repositories (such as Docker containers for test tooling). What About Releases? At this time, OPNFV major releases are on a regular six-month cadence. Creating releases on a regular rhythm is a common practice amongst open source projects. Close to the release date, the focus shifts from adding new functionality to bug fixes. The release team also makes decisions

Articles in this issue

view archives of White Papers - Understanding OPNFV