Page tree
Skip to end of metadata
Go to start of metadata

Introduction

This and child pages give information about

  • what XCI aims to do
  • how the XCI Framework is developed
  • how the scenarios that utilize XCI can be released
  • how the XCI itself can be released
  • way of working with XCI

Enabling Continuous Delivery

 

By definition, Cross Community CI (XCI) initiative aims to introduce Continuous Delivery (CD) way of working to OPNFV and the other communities it works with by working against master branches of the projects in order to
  • shorten the time it takes to introduce new features
  • make it easier to identify and fix bugs
  • ease the effort to develop, integrate, and test the reference platform 
  • provide additional feedback to upstream communities OPNFV works with and to OPNFV itself from production-like environment
  • increase the visibility regarding the state of things at all times

XCI enables this by applying basic CI/CD & DevOps principles and following best practices such as 
  • fail fast, fix fast
  • always have working software
  • small and frequent commits
  • work against the trunk, shortening time to develop
  • fast and tailored feedback
  • everything is visible to everyone all the time

and so on.

By doing this, the overall quality of the platform components provided by the upstream communities will increase greatly, making it easier for anyone to consume them when they need them with less trouble, helping to find and fix bugs much earlier than what it is today and develop new features. How good this works also depends on the nature of the changes; if the changes are atomic and more importantly complete, the value added by XCI will increase significantly.

Apart from applying the principles and following the best practices, XCI puts the users and developers first by pushing for
  • empowering developers by hiding the details that are generally not so interesting or concerning for the developers
  • reduced complexity
  • an easy way to try and develop things
  • choice
  • speed, helping developers to bring their scenarios to OPNFV fast
  • real scenario ownership

The proof of the user and developer centric approach is that the first thing XCI made available is the sandbox for the users to try things out and for the developers to develop things.

Another and perhaps the most crucial concern for XCI is to  keep the quality high, increase the confidence, have predictability, and have the availability of the latest versions earlier. Some of the prerequisites to fulfill these goals are
  • Test early and often
  • Know the quality at all times
  • Make the platform available early so people have time to develop, integrate, and test their work
  • Avoid big bang uplift
  • Avoid surprises

XCI Framework 

The framework provided by XCI is as thin/dumb as possible, keeping the overhead as little as possible and not getting in the way between the developers and what they are doing, whether they are in the upstream or in OPNFV.

This is due to the fact that all the work that is required to develop a new feature, integrate a certain component, or compose a new scenario will either be done in corresponding OPNFV projects or upstream projects, making sure XCI can do what the name implies; Continuous Integration.

Applying principles and following best practices will also ensure that XCI to always have a working/well tested version of OpenStack master so the users, developers, testers, and the CI will have chance to move at a faster pace and with increased agility.
The working version is also provided to developers and users as a sandbox so people will have the possibility and the ability to work locally which is where the CI actually starts; on developer laptop.

Apart from having the technical solutions, XCI will also have guidelines/examples and the XCI Team will support the projects moving forward as necessary.

If we need to reiterate based on the points above; XCI is a way to get features and components integrated upstream to get scenario running in OPNFV at a much faster pace.
This will also help us focus on the platform itself and the features & scenarios rather than what deploys the platform.

  • No labels