Happy ever afters with ci workflow
Download as DOCX, PDF0 likes414 views
The document outlines expectations for software development projects, including seamless and on-time releases, independent environments, high quality with few bugs, and ensuring everything is under control. It also describes bad practices like cloning databases manually, lack of testing, and content being overwritten. A CI/CD workflow is proposed to address these by automating processes, enabling flexible and planned releases through continuous integration and independent deployments.
![○ 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!
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](https://image.slidesharecdn.com/f9ay4zcwtropojzlrufa-signature-8ffea4f27544f0b0c42cbdb3149177c289bfebc62e320df3b7bcc3223d730b99-poli-151215001953/85/Happy-ever-afters-with-ci-workflow-4-320.jpg)
![○ 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](https://image.slidesharecdn.com/f9ay4zcwtropojzlrufa-signature-8ffea4f27544f0b0c42cbdb3149177c289bfebc62e320df3b7bcc3223d730b99-poli-151215001953/85/Happy-ever-afters-with-ci-workflow-5-320.jpg)
Ad
More Related Content
What's hot (20)
Viewers also liked (18)
Ad
Similar to Happy ever afters with ci workflow (20)
Ad
More from Albina Tiupa (15)
Happy ever afters with ci workflow
- 1. Expectations: Expectation1: Clientswantall releasestogoto productionseamlesslyandontime Expectation2: PMs want easilymaintainmultiple independentenvironments Expectation3: Clientswantreleasestobe of a highqualitywithminimumpostproductionbugs Expectation4: PMs want developmentteamtofeel responsible fordeliveredcode Expectation5: PMs want deploymenttobe independentfromthe entire team(orasingle person)
- 2. Expectation6: ClientsandPMs wantto be sure that everythingisundercontrol! Typical bad practices: - cloningdatabasesdownstream - manuallyreproducingcontentonprodenvironments - followingaseriesof error-prone manual stepsoneachenvironment - lack of QA (code reviewandmanual/automatedtesting) - contentgetsoverridenonprod - teammembersdonot followdisciplines/processesthe teamagreedtofollow - donotfeel responsibility - QA isdone aftercode is mergedtomasterbranch - Development/QA environmentdoesn’tresemble the prodenvironment
- 3. @Alex:shall we provide anycomparisonwithotherexistingCIsolutions? - "Thisisa kindof magic: howa PM can launchthe rocketsto the sky".A short overview of the CIBOXworkflowfrom non-technical perspective Demo: - "Doesitevenmatterfor myclients?". Keypoints:minimumpostdeploymentbugs,shorterUATperiod,flexibility,releasescanbe stable andplannedin advance,parallel work onmajorprojectscope andSLA tasksetc. 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 ○ Expectation1: Clientswantall releasestogoto productionseamlesslyandontime ○ Expectation2: PMs want easilymaintainmultiple independentenvironments ○ Expectation3: Clientswantreleasestobe of a highqualitywithminimumpostproductionbugs
- 4. ○ 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! 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
- 5. ○ 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