Expectation6: ClientsandPMs wantto be sure that everythingisundercontrol!
Typical bad practices:
- followingaseriesof error-prone manual stepsoneachenvironment
- lack of QA (code reviewandmanual/automatedtesting)
- teammembersdonot followdisciplines/processesthe teamagreedtofollow - donotfeel responsibility
- QA isdone aftercode is mergedtomasterbranch
- Development/QA environmentdoesn’tresemble the prodenvironment
@Alex:shall we provide anycomparisonwithotherexistingCIsolutions?
- "Thisisa kindof magic: howa PM can launchthe rocketsto the sky".A short overview of the CIBOXworkflowfrom
- "Doesitevenmatterfor myclients?".
Keypoints:minimumpostdeploymentbugs,shorterUATperiod,flexibility,releasescanbe stable andplannedin
advance,parallel work onmajorprojectscope andSLA tasksetc.
● Introduce Albina
● Introduce Alex
● We are remote team!
● One day we’ve realized that workflow and development process is a 90% of success
● Let's see why it is so
○ Expectation1: Clientswantall releasestogoto productionseamlesslyandontime
○ Expectation2: PMs want easilymaintainmultiple independentenvironments
○ Expectation3: Clientswantreleasestobe of a highqualitywithminimumpostproductionbugs
○ Expectation4: PMs want developmentteamtofeel responsible fordeliveredcode
○ Expectation 5: PMs wantdeploymenttobe independentfromthe entire team(ora single person)
○ Expectation6: ClientsandPMs wantto be sure that everythingisundercontrol!
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!
● 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
○ Code Driven Development
○ Prototypes vs on fly
○ Review(Knowledge exchanging)http://cdn.meme.am/instances/500x/54727623.jpg
○ Automate everything
■ 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
○ 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
● 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.
● CIbox workshop, please fill out form.
● You can find us [bla, bla]