Recommended
More Related Content
Similar to DevOps culture
Similar to DevOps culture (20)
Recently uploaded
Recently uploaded (20)
DevOps culture
- 2. Who am I? Krisztian Papp Email: krisztian@letscode.hu Twitter: @tacsiazuma Podcast speaker / Software dev / Blogger Screencast creator: https://app.letscode.hu Private pilot @Cloudera
- 3. Rural development “What is a countryside?” “How can you differentiate it from the city?” “What is a city?”
- 4. What is DevOps? - Product? - Toolchain? - Job title? - Containers? - Kubernetes? - CI/CD? - Goal?
- 7. Back to the origins Source: https://ew.com/article/2015/07/02/back-to-the-future-anniversary-reviews/
- 8. PDD (punch card driven development) Source: https://www.bcs.org/articles-opinion-and-research/what-were-punch-cards-and-how-did-they-change-business/ - Write code by hand - Hand it over - Receive the punched cards - Hand it to ops - Receive output
- 9. PDD (punch card driven development) - Development is slow - Debugging is hard - Logs do not exists (the OS uses all the HDD) - The speed is restricted by the mainframe
- 10. Samba driven development (PHP) - No version control - The network share is slow - People stepping on each other - Debugging is hard - Logs exists but might be inaccessible - Developing on prod
- 11. The new origins Source: https://mubi.com/films/back-to-the-future
- 12. Modern punch card (banks) - No environment to run - Handmade package - Merge hell - Compiled by hand - Deployment_instructions.docx - No fast feedback
- 13. How did we reach this?
- 14. How did we reach this?
- 15. How did we reach this?
- 16. How did we reach this? Source: https://www.gisreportsonline.com/r/french-bureaucracy/
- 17. Adding some agile to the mix - Small iterations - No merge hell - Possible to release often - Approval chain - Release is still a literal event
- 18. How can we match up the speed? - Product? - Toolchain? - Job title? - Containers? - Kubernetes? - CI/CD?
- 19. A story of poorly implemented “devops” - Terraform - Kubernetes - IaaC - Missing and/or outdated documentation - No self-service - 2 weeks to get a slack response from the SRE
- 20. What is DevOps? - Product? - Toolchain? - Job title? - Containers? - Kubernetes? - CI/CD? - Goal?
- 21. DevOps is ... - A mindset - A shared attitude - A way to confidently develop software - A culture to be nurtured and improved - Collaborative - Iterative - Learning - Mentoring - …and so much more
- 22. Further reading
- 23. Q&A
- 24. Thank you for your attention!
Editor's Notes
- Agrár szak Vidékfejlesztés, heti 4 óra tömbösítve Mi az a vidék? Ugyanez a kérdés az év végéig, de senki se tudja igazán
- hogy kapcsolódik ez a vidék dolog ide A devops fogalmával hasonló a helyzet Product - azure devops? Toolchain - verziókövetés, monitoring, stb? Devops engineer? Konténerek, az olyan menő K8s az még menőbb ci/cd ez már biztos az lesz, megnyomoma gombot és kint van prodon A devops lenne a cél?
- Ha csak a szóösszetételt nézzük, akkor ez a két fél van a játékban, de igazából nem igaz
- A fejlesztő fejleszteni akar, hiszen az viszi előre a céget A tesztelő tesztelni az új dolgokat, hiszen az adja a munkáját Az üzemeltetés pedig nyugodtan aludni
- Na de menjünk kicsit vissza az időben és nézzük meg, hogy is ment ez régebben
- Hogy nézett ki a devops akkoriban? A lyukkártya pakli első kártyáján volt név, cim, telefonszám, hogy tudják kihez tartozik az adott job. A lyukkártyákat, amikor beütötted, akkor a tetejére gépelte a szöveges formáját, ez segitette a fejlesztöt, hogy időben észrevegye, ha valami nem stimmel. Sorszámot is tudtak gépelni rá, hogyha véletlen valaki leejti, akkor könnyen sorba tudja rendezni, hisz lehet ez nem a fejlesztője volt és még ő se tudná a sorrendet. Sőt, volt olyan gép, ami a sorszám alapján sorbarendezte, csak piszok drága volt. A kártyák egyik sarkán volt egy kis lecsipés, ami megakadályozta, hogy forditva kerüljön be a gépbe, és aztán mindenféle huncutságot okozzon
- Nincs version control, vagy ha van a samba miatt bitang lassú, ftp se a legkényelmesebb, de ami ott van, az ott van
- Menjünk egy kicsit előre az időben
- Megirod a kódot egy olyan helyen, aminek köze sincs az éleshez, nem is tudod elindítani sok esetben. Kézzel gyártott archivum, van hogy speciális IDE plugin kell hozzá fix IDE verzióval Ha többen dolgoznak, akkor hosszas feature branchek, már ha vannak branchek Kézzel van lefordítva, ez is lehet nem is portolható máshova, vagy ha igen nincs doksi hogy kell, lassú onboarding Deployhoz instrukciók leírva Ops megkapja, szombat hajnalkor elpattan Ha valamit elszúrtál fél éve, akkor a release napján kapd elő a fejedből, mert fixálni kéne
- Kezdetben nem volt ellenségeskedés és bürokrácia az ops és dev team közt
- A gond az, hogy az ownership a fejlesztőknél sokszor már ott megszűnik, hogy becommitolta a kódot. Valami kijut az élesre és ott nem jó, akkor megy az ujjal mutogatás Erre értelemszerűen az ops bevédi magát, hogy oké, csak akkor mehet ki, ha QA letesztelte a stagen QA signoff
- Dev team: jaj, hotfix, gyors hadd menjen ki, QA nem tudta még tesztelni, lécci Bumm, eltörik élesen
- OPS bedurvul Egyre több approval kell hogy kimenjen valami Hiába van valami készen, várni kell, hogy kijusson
- Apró iterációk Rövid életű branchek Kevesebb merge hell, ha van egyáltalán Sűrűn van lehetőség releaselni Ki kell várni az approveokat, le kell szervezni a release meetinget, kiválasztani a dátumot, behivni rá a fejeseket, stb
- Hogyan lehetne a két csapat sebességét egy szintre hozni? Sokan esküsznek mindenféle eszközre, de azok nem fogják megoldani a gondokat. Az, hogy majd felveszünk egy embert, aki hídként szolgál az ops és a dev csapat között egy téveszme A konténerizéció, kubernetes csak egy eszköz, ami persze segít majd az út során, de nem megoldás CI/CD, jól hangzik, de ez sem fogja megoldani a gondot, kitoljuk élesre és majd lesz valami?
- Adott egy projekt, át kell migrálni egyik infráról, amit eddig mi menedzseltünk egy másikra Minden buzzword adott, terraform, kubernetes, infra as a code A gond csak az volt, hogy hiányos, régi doksikon át kellett ezt megtenni Semmi self service, mindent be kell hányni nekünk a repoba, amivel nem is lenne baj Csak semmi guidance, hogy is kellene eligazodni a dolgokon és 2 hét mire slacken válaszol az SRE… egy senior director kérdésére.
- Először is ez egy mindset, amit valahogy magunkénak kell tudni De nem csak megunknak, hanem másoknak is, ugyanis ebben mindenki benne van, nem csak a devops engineer, ahogy szokták mondani A cél az, hogy úgy tudjunk szoftvert fejleszteni, szállitani, hogy nem ütközünk lépten nyomon akadályokba Ahogy az előadás címe is mondja, ez egy kultúra, kultúrális változást igényel, ami baromi nehéz és sokáig tart Ahogy mondtam, ebben együtt vagyunk benne, össze kell dolgozni a dev és ops teamnek is benne Iterativ, mivel nem fog elsőre sikerülni, sőt másodjára sem, mivel mindig van hova fejlődni Tanulni kell hozzá, a dev csapatnak egy kicsit az opstól, az opsnak pedig a devtől, mert van átfedés, hogy jobban megértsék egymást. Legjobb ha céges szinten megy, meetupok, brown bagek, stb. És segíteni is kell hozzá egymásnak, csapaton belül vagy azok közt Rengeteg mindent lehetne még hozzátenni, hogy mi az és mi nem az, vagy épp mi a rossz gyakorlat, de nem férne bele az időnkbe…
- Itt van három ajánlott irodalom azoknak, akiket érdekel a téma A devops handbook az ilyen case study gyűjtemény, különböző cégektől A Continous delivery kicsit régebbi, de nagyon sok koncepciót szült amiket ma a devops szó mögé sorakoztatnak fel Az SRE könyv az a google saját kis sztorijait tartalmazza, hogy mentek félre dolgok, hogy fixálták meg azokat, hogy zajlott a root cause analysis és ilyenek