“One reason to save money by using CICD for OpenStack” 1/28/16 draft version

Anton Khaldin

Reason to save money with CICD

opensource specific

Best practises in CICD

proposal for components

Yet another reason to save money with open source

save money

reduce cost

risk management

release managementchange management

data driven decisions

“CICD” can collect dataand store CICD events

One reason to save money by using CICD for OpenStack

opensource specific

● OpenStack is not a product● many open source projects are not products● without product there is no production

product -> release management and change management -> dependencies management

you need to provide Compatibility Matrix

1) to your clients 2) to operation team

● Compatibility matrix: - feature list - config options - version of dependencies ● 1) for current version of product in production. 2) for next version of product.

Building product from open source, from OpenStack.

Best practice in CICD

● dev team should/can response for product● dev team should be flexible to change dev methodology, sprint size, release

cycle, should plan delivery, flexible to change tools in dev env.● Fail First development ( test driven development, data driven development)● "commit in production"

- devops should be inside of dev team. as well as rm engineer, ci engineer, qa engineer.

Fail first strategy

What if you- want to take open source project/projects and create internal product

(productionize) product - to control

- release of features (release cycle),- feature list, - supportable configurations (conf options and combinations of options)

- to be independent from service provider

- to increase level of technology adoption

What if you- have few internal dev teams - need to provide single service endpoint - have one operation team to manage more than 10 different instances of

same product- your client’s expectation is API as a product.

- with list of supported api calls and supported options.

little bit more specific: CD for OpenStackone of most important part of CD for OpenStack is deployment automation

- do you have CI for your deployment automation solution ?- do you have test automation for your deployment automation ?

- what about support of fully automated deployment ?- what about support of upgrade ?- what about support of roll back ?

Maurice Herzog 1950

1953: Sir Edmund Hillary and Tenzing Norgay

Gri gri is an assisted braking belay device designed to help secure rock-climbing, rappelling, and rope-acrobatic activities.

deliver feature to cloud = reach cloudIaaS cloud is on top of rocks and ice

Critical components of CICD● no magic solutions: CI and CD processes are unique.● few principles can be used as a starting points:

○ CICD is an empty box/container without test automation

○ main output from CICD is data/certification reports that can help to manage risks in release decision/operation decisions

○ data: test reports, configuration, list of feature, dependencies versions

Components:

1. Test automation2. Reference environment ( Dev /CI lab env) -- shareable in time sharing manner

( like timesharing os, mainframe,cluster) , self service3. DataStore ( data structures and api calls to maintain reports in consistency

with some agreements/policies)

Design session or Demo ?

codename for tools:

gurkhali - command line tool -----> reference to Maurice Herzog . He led the expedition that first climbed a peak over 8000m, Annapurna, in 1950, and reached the summit with Louis Lachenal. His sherpas were gurkhali(nepali) because his expedition started not from China side.

sleet - server-side component CI lab automation to manage and clean resources (hardware servers, network (L2 L3 resources)

grigri - datastore for certification data and CICD events ( maintain consistency with agreements and decisions )

my-local-linux-box$ gurkhali giveme squiggle time = 4 config-version = w

1) Squiggly means OpenStack release 2) 4 means 4 hours - hardware machines will be cleaned up after 4 hours

3) after 4 hours config, logs, test reports, ansible facts will be published in datastore report with uniq id

my-local-linux-box$ gurkhali giveme report list

----- list of report provided

my-local-linux-box$ gurkhali create release-candidate 5775

my-local-linux-box$ gurkhali promote release-candidate 5775 to prestage

Product -> Api calls -> data structures -> data flows.

Blueprint is ready. Let's take a bit of critical thinking on it. Let's take a bit of critical thinking from community.

Contribution in OpenStack

● contribution it is not donation ○ when you give something for free sometimes. No one tell you thank you, they will try to broke

it.

● contribution it is periodical ( continuous ) collaboration . It is engage for future investments to community. to verify, to validate, save money in global scale.

○ because your customers are your investors and your investors are your customers.

● contribution is daily hard work

Yet another reason to save money by using open source and CICD.

For hard work you should have good motivation.

● contribution it is not a donation● contribution it is competitive advantage on global market

○ it is method of risk management■ community it is a way to verify

● you are using proofed technologies● you are ready for competition on open markets● you are using open technologies ● you are fast to react in real-time on challenges in open world.

● contribution it is way to integrate internal team and resolve/merge internal conflicts ( conflict of interests, of ideas, initiative)

risk management technique can accelerate- CICD should reduce gap between dev and prod- short CICD cycle can became driver of development - it is easy to evaluate

- but without rollback automation it is not a case

Thanks !