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.

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

8. Nostalgia
We were patient
8

9. Nostalgia
Car automation
9

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
Vireshdoshi@time2test.co.uk
57