Devops Journey - internet tech startup
Download as PPTX, PDF0 likes1,186 views
This document summarizes the experience of a QA consultant working with a tech startup to implement DevOps practices to improve their software development process. The consultant found the startup was stuck in outdated practices from the 1980s, with no automation, poor source control, and manual testing and deployment. The consultant implemented continuous integration using tools like Jenkins, test automation with Behat and Mink, and automated deployment. This eliminated errors, provided visibility, and allowed developers to focus on development. While progress was made, the consultant notes further improvements are still needed, especially adopting better Agile practices.
Ad
More Related Content
What's hot (20)
Viewers also liked (20)
Ad
Similar to Devops Journey - internet tech startup (20)
Ad
More from Viresh Doshi (6)
Recently uploaded (20)
Devops Journey - internet tech startup
- 3. About In this slide deck I share my experience, journey and thinking with working with a tech startup who needed help with QA, Automation and CI. What I gave them was DEVOPS 3
- 4. About me – Viresh Doshi My background is in QA ( over 15 years exp.) Specialize in delivery and change I identify areas that need improvement and then delivery solutions. Still learning Enjoys sharing experience and collaboration 4
- 5. About the tech startup they provide software to ecommerce outfits that help them better understand their and increase their customers’ shopping experience. The goal being to increase revenue. 5
- 6. Doesn’t make sense A tech startup stuck in the 1980s. How can that be? Erm, not exactly sure…perhaps the existing technology team don’t have new industry experience… 6
- 7. What is wrong with the 80s? The décor The toys The technology The tv shows The haircuts OK, I secretly love the 1980s! 7
- 10. Nostalgia We loved to share… 10
- 11. Nostalgia We saved important data on this… 11
- 12. What does it mean? DevOps – A term that comes from Agile that is focused on how businesses can embrace technology to delivery better results and win. Automation testing – use of special software to control the execution of tests that compare actual outcomes with predicted outcomes. Continuous Delivery – engineering approach to reliably produce software in short cycles. 12
- 13. My Approach I initially work with their manual processes. I learn and document their product, relevant business areas and systems. I work through at least two software cycles to understand the end to end processes: Dev, test, build, release, production, hot fix cycles. 13
- 14. My Approach I then present my findings with solutions and technology decisions to the sponsors and get their buy in. I start working on the jigsaw puzzle and incrementally piece together using a CI approach. I switch on systems and increase visibility. 14
- 16. No Agile/SCRUM No Product owner No Scrum master No retrospectives or planning meetings No triage No Backlog grooming ( too many tickets) 16
- 17. No Agile/SCRUM No statistics and reporting No Daily standups ( well, a daily meeting that lasted 30 mins) 17
- 18. No Automated Builds The builds were packaged manually from 3 separate Code Repositories Binaries compiled and manually placed. The builds contained “rubbish” The builds contained manual version numbers Impossible to point out issues. 18
- 19. No automation testing No regression testing No functional testing Test execution loosely conducted against a development environment by developers and other members in the business. 19
- 20. Untidy environments Just the development environment and “staging environment” which was built ad hoc and from source code instead of the “build” Never the latest version 20
- 21. Manual Release notes The release notes are manually generated using a word processor and then converted to a PDF and manually added to the source code repository. 21
- 22. Too many silly mistakes Incorrect versioning on document, database, front end and packaged builds. Missing items in the release Incorrect software Non tested database scripts that failed to execute 22
- 23. Developers focus Senior developers doing basic repetitive tasks instead of focusing on developing. Unnecessary time taken away per cycle. Everything was rushed and the quality suffered. 23
- 24. Office fit for David Brent The office was located in a business park with no access to a gym or decent coffee shops 24
- 25. Source Control Binaries built manually and then stored in source control. 25
- 26. No virtualized test environments Despite Virutalisation servers being available, they were not used for test/dev/staging/CI environments. 26
- 27. JIRA tickets lacked info Tickets contained very little information. Too much haste and information lost in emails 27
- 28. Manual install to Production Installation to production servers carried out manually by developers. 28
- 29. Poor build management Generally speaking, the function and ownership of build management was neglected/non existent. 29
- 31. Challenges Old school thinking and working Lack of experience in new methods Winning business and juggling installations 31
- 32. Client Challenges Juggling two product deliveries. Looking to expand the tech team Existing development team are very clever Time to learn and implement 32
- 33. My challenges I interface with lots of different technologies which means slower starts and quick learning. Build momentum to increase efficiency. Use the client’s technology stack ( don’t introduce Java when the client is using PHP) Stick to the vision 33
- 34. Vision and principles Automate the journey from code check in to production. Eliminate all silly manual errors Preserve manual test data for automation. Use a BDD approach to test automation – embrace Gherkin 34
- 36. Build contains more action At the end of every monthly cycle, the build now contains more fixes and more functionality than before. 36
- 37. Developers don’t build The build process has been automated and completely taken away from the developers. Code go through static analyzers The final release zip is packaged and built automatically for every code check in. 37
- 38. Eliminated silly errors Silly errors were found only at the end of the release cycle and on production such as wrong versions in PDF documents. Incorrect binaries. Missing folders, dev code e.t.c 38
- 39. Visibility into Dev work The radiator view provided by Jenkins CI now allows the business and sponsors to see progress and status across the SDLC. Green is good and Red is worrying. Development Manger can see progress and inspect code check-ins. 39
- 40. Automated deployment Every code check is deployed to a virtualised Staging CI environment where it is installed automatically as it would be on a client site. 40
- 41. Smoke testing An automated smoke test is executed for every code check in to ensure that the integrity of the end to end system is still in tact. This provides confidence that nothing fundamental is broken. 41
- 42. All test artifacts stored in GIT GIT is used as a storage space for all test artifacts created which massively increases the resuse. 42
- 43. Tools used in OPS Tools created in QA and test are used in OPS to help with automated deployment to production servers. 43
- 44. Start up and Tear down concepts Introduced a startup and tear down concepts to create clean environments and settings and catch all errors. 44
- 45. Technologies used The dev team uses a LAMP stack and so it made sense to stick closely to what they already know. Mink , Behat, Jenkins CI, Bash, Virtualisation ( oVirt and AWS), Gherkin, BDD, PHING, Linux, JIRA, GIT, MySQL, Apache 45
- 46. Why behat and mink? Provide BDD capabilities. Behat uses the Gherkin language that uses natural language to express system behavior which can be shared between technical and non-technical people. Mink is a library that interfaces with the browser. 46
- 47. Why BASH? The Bash Scripting too opens up the doors to a plethora of command line linux tools. It can process huge amount of data and provide the important return codes for pass or fail. 47
- 48. Why Jenkins CI? Jenkins CI loves all sorts of jobs. It has 100s of extensions that allow you automate just about anything you want. It is CRON on steroids. It is lightweight with SSH connectivity to other servers and easy ability to execute SHELL commands. 48
- 49. Why PHING? PHING is a build tool similar to the original ANT. It’s primary usage is to neatly execute tasks by means of targets to say BUILD, TEST, RELEASE e.t.c . PHING compliments the LAMP stack. 49
- 51. Agile process Unfortunately, the team have not embraced Agile and it’s magic. This needs more culture and change management! 51
- 53. Going forward Move to 2 weekly release cycles – happy customers. Move to fully automated deliver to production Improve the Agile process 53
- 54. Going forward Refactor the DevOps code and increase efficientcy of the jobs Automate the relese notes. Overhead of new sytem maintenance need to be factored. Improve the eporting 54
- 55. The conclusions Time and money saved per release cycle Dev focus on development Eliminated School boy errors found at the client site. Faster feedback on regressions Increased visibility on Dev activities DevOps is about winning. This is the start and things can only get better. 55
- 56. Still stuck in the 80s? The real question: Are they still wearing shoulder pads? Or have they moved to the 90s with the advent of dialup modems and the infamous Netscape browser? 56
- 57. The End Get in touch [email protected] 57
Editor's Notes
- #4: To achieve Automation and CI, I had to tackle the wider SDLC issues. So, to successfully achieve test automation and CI, I needed to get initially tackle some of the other parts of the SDLC. Namely, build management , Source code repostiories and envrionments
- #5: Agile, DevOps, BDD, Web, Selenium, Jenkins CI, Virtualistaion, Linux
- #8: http://www.pastemagazine.com/blogs/lists/2014/11/the-80-best-tv-shows-of-the-1980s.html?a=1
- #9: We had all the time in the world. We would get up of our back sides and walk to the video cassette player, wait for it to rewind and hit eject which would make the whirling noises and finally eject in 10 seconds.
- #10: We had muscle power!
- #11: We had muscle power!
- #12: Year: 1984 One of the primary complaints about the Commodore computer line was its inability to save all data and programming when powered off. Those who couldn’t fork up the bread to purchase the 1541 floppy disk drive settled for the nearly similar and cost-efficient alternative in the 1531 cassette tape drive. Granted the compromise of running with the latter was a slower data transferring speed (50 bytes per second), it was a lifesaver for Commodore users who valued data.
- #13: http://devops.com/2015/05/13/surprise-broad-agreement-on-the-definition-of-devops/
- #17: The company methodology was very old skool.
- #37: Less Fart more action
- #38: Less Fart more action
- #47: http://tooky.co.uk/this-gherkins-not-for-reading/ http://tooky.co.uk/ - cucmber api BDD hooks http://www.jimmycuadra.com/posts/please-don-t-use-cucumber/
- #48: http://tooky.co.uk/this-gherkins-not-for-reading/ http://tooky.co.uk/ - cucmber api BDD hooks http://www.jimmycuadra.com/posts/please-don-t-use-cucumber/
- #49: http://tooky.co.uk/this-gherkins-not-for-reading/ http://tooky.co.uk/ - cucmber api BDD hooks http://www.jimmycuadra.com/posts/please-don-t-use-cucumber/
- #50: http://tooky.co.uk/this-gherkins-not-for-reading/ http://tooky.co.uk/ - cucmber api BDD hooks http://www.jimmycuadra.com/posts/please-don-t-use-cucumber/