Expectations:Expectation 1: Clients want all releases to go to production seamlessly and on time

Expectation 2: PMs want easily maintain multiple independent environments

Expectation 3: Clients want releases to be of a high quality with minimum post production bugs

Expectation 4: PMs want development team to feel responsible for delivered code

Expectation 5: PMs want deployment to be independent from the entire team (or a single person)

Expectation 6: Clients and PMs want to be sure that everything is under control!

Typical bad practices: - cloning databases downstream- manually reproducing content on prod environments- following a series of error-prone manual steps on each environment- lack of QA (code review and manual/automated testing)- content gets overriden on prod- team members do not follow disciplines/processes the team agreed to follow - do not feel responsibility- QA is done after code is merged to master branch- Development/QA environment doesn’t resemble the prod environment

@Alex: shall we provide any comparison with other existing CI solutions?

- "This is a kind of magic: how a PM can launch the rockets to the sky". A short overview of the CIBOX workflow from non-technical perspectiveDemo:

- "Does it even matter for my clients?". Key points: minimum postdeployment bugs, shorter UAT period, flexibility, releases can be stable and planned in advance, parallel work on major project scope and SLA tasks etc.

Introduction● Introduce Albina● Introduce Alex● FFW● We are remote team!

Preface● One day we’ve realized that workflow and development process is a 90% of success● Let's see why it is so

Problems, @Albina● Expectations

○ Expectation 1: Clients want all releases to go to production seamlessly and on time○ Expectation 2: PMs want easily maintain multiple independent environments○ Expectation 3: Clients want releases to be of a high quality with minimum post production bugs○ Expectation 4: PMs want development team to feel responsible for delivered code

○ Expectation 5: PMs want deployment to be independent from the entire team (or a single person) ○ Expectation 6: Clients and PMs want to be sure that everything is under control!

Conflict, @Alex @Albina● @Albina, ADD YOUR TEXT HERE● When you done project, how often you say to yourself: “WE HAVE TO CHANGE OUR PROCESS,

IT’S SHIT!” I'm sure ~70% of audience do this very often :) Even I do this regularly.● Main conflict:

○ 1st type of process - No process!○ 2nd type of process - CI workflow○ Everything else - no process.○ Why so?

● Wrong way [picture, slap shit together and deploy] - bad practices - 4-5(Changes directly on production etc.), @Alex

● Do you want get rid of that???

Problem solving(How to make your production smooth)● Caution! Addictive content goes next!

http://boombob.ru/img/picture/Jul/02/b5abaeef6dda6d4707e718fd4a53674b/10.jpg http://i99.beon.ru/i.imgur.com/fisxT.gif

● How our workflow looks like, @Albina○ Everything automated.○ PM can deploy anytime○ Remote team follows defined process○ You are forced to follow general process, since everything automated

● From technical perspective, @Alex○ Specifications○ Code Driven Development○ Prototypes vs on fly○ Review(Knowledge exchanging)http://cdn.meme.am/instances/500x/54727623.jpg ○ Automate everything○ http://i2.asp.net/media/48525/image012.png?cdn_id=2015-08-15-002

■ Not sure about following:○ Isolated features on every build○ No friday deployments http://s.mlkshk-cdn.com/r/YF94 ○ Flexibility about CI workflow configuration - DevOps○

● For PMs, @Albina○ Feeling of completed task/milestone - you can be 99% sure that task was properly tested by

minimum 2 people (reviewer and QA)○ You can be sure that test/staging environment is the same as prod - no unique non-

reproducible prod issues ○ Developer is always responsible for his/her feature (during project) - all bad code is detected

by reviewer, no right for mistake, dude :)

● For Clients, @Albina ○ Shorter UAT period = Minimum postdeployment bugs - your clients can relax and enjoy the

process○ Flexibility to work on multiple versions/scopes on one project (SLA, Hotfixes for example) -

○ Releases can be stable ○ Flexibility about planning releases in advance○ Demo for the client can be held on whatever environment is up-to-date

Summary ● Why is it so important? @Albina, @Alex

○ High quality product delivered - management & customers are happy○ Result of our work immediately used by end-users○ Team is constantly improving its skills and expertise

● And our life is divided into 2 parts: before CI workflow and after CI workflow.● As result was born Open Source project CIbox.

End● CIbox workshop, please fill out form.● You can find us [bla, bla]● Questions