1. Open-O Integration Project Introduction
Integration Shanghai
August 29, 2016

2. Goals
Provide all the common and cross-project infrastructure code, setup, processes, etc.
Avoid duplication of effort
Make project teams’ lives easier
“We take care of things so you don’t have to”
We are here to help you

3. “We”: the Integration project team
Roles
“We”: the Integration project team
“You”: all Open-O project teams and contributors
Each Integration committer has two roles
Integration team member
Help Integration project provide services to others
Representative of another project
Act as liason to convey project-specific requirements, updates, etc.

4. Overview
What services will Integration provide?
How do projects leverage these services?

5. What Integration Will Provide – Release 1
O-Parent
Shared common defaults
CI-Management
Jenkins Job Definitions
Test
Automation of unit and system test flows
Autorelease
Builds all projects from scratch / cross-project dependency validation
Distribution
End-user scripts, config files, README
POC
Scripts for setting up POC sample deployment

6. Tool Infrastructure Code / Unit Test Repository (Git/Gerrit)
System Test
Repository
(Git/Gerrit)
Artifact
Repository
(Nexus)
Build / Unit Test
(Jenkins, Maven)
System Test
(Robot Framework)
Contribution Activity Reports
(Bitergia or Spectrometer)
API Documentation
(Swagger)
Unit Test
Code Coverage Reports
(SonarQube)
System / Performance Test Reports
(Robot, JMeter)

7. O-Parent License check Nexus setup Checkstyle Static code analysis
Apache License Version 2
Nexus setup
POM <distributionManagement> tag
Checkstyle
Google Java Style Guide
Static code analysis
E.g. FindBugs

8. Apache License Version 2 Mandatory Sample header text
License Check
Apache License Version 2
Mandatory
Build fails if license header is missing
Sample header text
oparent/license/doc

9. Checkstyle Consistent code style Non-Mandatory
Simplifies code reviews and version comparisons
Eases code contribution into multiple projects
Non-Mandatory
Style violations reported as warnings
Build will not fail when there are style violations
Projects encouraged to minimize style warnings

10. Google Java Style Guide
Well-known and well-documented
Saves us from writing our own style document
Excellent tooling support
Built-in support in Checkstyle tool
IDEs (Eclipse, IntelliJ, etc.)
Command-line formatter

11. CI-Management (Jenkins)
Per Patch
Periodic (Daily)
Patch Submission
Patch Merge
All Projects Build From Source
Deploy to Nexus
Single Project Build /
Core Unit Tests
Single Project Build /
Core Unit Tests
All Unit Tests
All Projects Build From Artifacts
Check
Cross-Project Dependencies
Deploy to Swagger
Deploy to SonarQube
Project-Dependent System Tests
All System Tests

12. Jenkins JJB Job Types Verify (patch submission) Merge (patch merge)
Build project and run unit tests (mvn clean install)
Check for cross-project dependency issues (e.g. circular/unsatisfied dependencies)
Merge (patch merge)
Deploy project SNAPSHOT artifacts to Nexus (mvn deploy)
Run project-dependent system test suites
Periodic (daily)
Run full, clean build of all projects from source
Run all unit tests and system test suites

13. Unit Tests Single project Feature/function tests
Tests at the class/method level (JUnit)
Tests using mock servers/APIs or stubs
Source controlled in each project’s own repo
Run with Maven
Core vs. Comprehensive
Core: run at every patch submission/merge
Comprehensive: run on periodic basis (e.g. daily)

14. System Tests Cross project Performance tests
E.g. latency, throughput, longevity, scalability
Tests using live servers, VMs, containers
Source controlled in Integration project repo
Run with Robot Framework
Project-Dependent vs. All Tests
Project-Dependent: run at patch merge
All Tests: run on periodic basis (e.g. daily)

15. System Test Suite Repository
Source controlled in:
integration/test/csit/suites/{project}
Each project
May have multiple test suites
Divided into functional areas
Specifies its upstream project dependencies
Project-Dependent test suites
all test suites marked as dependent on a project
E.g. if GS-O is dependent on NFV-O, then GS-O test suites are run when NFV-O is changed

16. How to Leverage Integration’s Services, Part 1
Use provided Jenkins JJB templates
Found in ci-management/jjb
{project}-verify-java
{project}-merge-java
Project structure
Inherit from O-Parent
Define Top-Level POM
If the repo contains only a single top level directory, consider moving its contents to the root

17. How to Leverage Integration’s Services, Part 2
Set up ~/.m2/settings.xml
Allows pulling artifacts from Open-O’s Nexus server
Get sample copy from oparent/settings.xml
Make Java source code compliant
Add Apache License Version 2 header
Format Java source code into Google Java Style
Use Google Java Style formatters for IDEs
Consider auto-formatting on save

18. How to Leverage Integration’s Services, Part 3
Organize unit tests
Core: critical feature/function tests
Comprehensive: tests that are time-consuming
System test suites
Guidelines TBD
Swagger API Documentation

19. How to Leverage Integration’s Services, Part 4
Provide build / deployment requirements
RAM requirements, Linux version, Java version, etc.
Configuration files used
How to run each module

20. How to Leverage Integration’s Services, Part 5
Avoid re-inventing the wheel / duplicating effort
If the defaults don’t work for you, talk to us
Ideas that may be useful for all projects are always welcome
Help us help you! If anything can be done in a better way, just ask

21. Thank You for Your Contribution
We are here to help
We also need your help
Let’s work together to make Open-O successful!

22. Integration mailing list
Q&A
Q&A
Integration mailing list