devops journey - internet tech startup

DEVOPS Journey:

Internet tech startup

My experience with a technology

startup who was stuck in the 1980s

BackgroundWhat’s this about?

AboutIn 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

About me – Viresh DoshiMy background is in QA ( over 15 years exp.)Specialize in delivery and changeI identify areas that need improvement and then delivery solutions.Still learning Enjoys sharing experience and collaboration

4

About the tech startupthey provide software to ecommerce outfits that help them better understand their and increase their customers’ shopping experience. The goal being to increase revenue.

5

Doesn’t make senseA 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

What is wrong with the 80s?

The décorThe toysThe technologyThe tv showsThe haircutsOK, I secretly love the 1980s!

7

NostalgiaWe were patient

8

NostalgiaCar automation

9

NostalgiaWe loved to share…

10

NostalgiaWe saved important data on this…

11

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

My ApproachI 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

My ApproachI 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

Where were they before I was unleashed?Before DEVOPS

No Agile/SCRUMNo Product ownerNo Scrum masterNo retrospectives or planning meetingsNo triageNo Backlog grooming ( too many tickets)

16

No Agile/SCRUMNo statistics and reportingNo Daily standups ( well, a daily meeting that lasted 30 mins)

17

No Automated BuildsThe builds were packaged manually from 3 separate Code RepositoriesBinaries compiled and manually placed.The builds contained “rubbish”The builds contained manual version numbersImpossible to point out issues.

18

No automation testingNo regression testingNo functional testingTest execution loosely conducted against a development environment by developers and other members in the business.

19

Untidy environmentsJust the development environment and “staging environment” which was built ad hoc and from source code instead of the “build”Never the latest version

20

Manual Release notesThe release notes are manually generated using a word processor and then converted to a PDF and manually added to the source code repository.

21

Too many silly mistakesIncorrect versioning on document, database, front end and packaged builds.Missing items in the releaseIncorrect software Non tested database scripts that failed to execute

22

Developers focusSenior developers doing basic repetitive tasks instead of focusing on developing.Unnecessary time taken away per cycle.Everything was rushed and the quality suffered.

23

Office fit for David BrentThe office was located in a business park with no access to a gym or decent coffee shops

24

Source ControlBinaries built manually and then stored in source control.

25

No virtualized test environments

Despite Virutalisation servers being available, they were not used for test/dev/staging/CI environments.

26

JIRA tickets lacked infoTickets contained very little information.Too much haste and information lost in emails

27

Manual install to Production

Installation to production servers carried out manually by developers.

28

Poor build managementGenerally speaking, the function and ownership of build management was neglected/non existent.

29

Time to ponder and assimilate the info.

Thinking

ChallengesOld school thinking and workingLack of experience in new methodsWinning business and juggling installations

31

Client ChallengesJuggling two product deliveries.Looking to expand the tech teamExisting development team are very cleverTime to learn and implement

32

My challengesI 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

Vision and principlesAutomate the journey from code check in to production.Eliminate all silly manual errorsPreserve manual test data for automation.Use a BDD approach to test automation – embrace Gherkin

34

What the world looks like after my vision?After DEVOPS

Build contains more action

At the end of every monthly cycle, the build now contains more fixes and more functionality than before.

36

Developers don’t buildThe 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

Eliminated silly errorsSilly 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

Visibility into Dev workThe 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

Automated deploymentEvery code check is deployed to a virtualised Staging CI environment where it is installed automatically as it would be on a client site.

40

Smoke testingAn 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

All test artifacts stored in GIT

GIT is used as a storage space for all test artifacts created which massively increases the resuse.

42

Tools used in OPSTools created in QA and test are used in OPS to help with automated deployment to production servers.

43

Start up and Tear down concepts

Introduced a startup and tear down concepts to create clean environments and settings and catch all errors.

44

Technologies usedThe 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

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

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

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

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

What wasn’t achieved

Rome was’t built in a day

Agile processUnfortunately, the team have not embraced Agile and it’s magic. This needs more culture and change management!

51

Let’ s wrap this upConculsions

Going forwardMove to 2 weekly release cycles – happy customers.Move to fully automated deliver to productionImprove the Agile process

53

Going forwardRefactor the DevOps code and increase efficientcy of the jobsAutomate the relese notes.Overhead of new sytem maintenance need to be factored.Improve the eporting

54

The conclusionsTime and money saved per release cycleDev focus on developmentEliminated School boy errors found at the client site.Faster feedback on regressionsIncreased visibility on Dev activities DevOps is about winning. This is the start and things can only get better.

55

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

The EndGet in touchVireshdoshi@time2test.co.uk

57