How to Troubleshoot Apps for the Modern Connected Worker
Devops Journey - internet tech startup
1.
2.
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
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
15.
16. No Agile/SCRUM
No Product owner
No Scrum master
No retrospectives or planning meetings
No triage
No Backlog grooming ( too many tickets)
16
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
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
35.
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
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
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
Agile, DevOps, BDD, Web, Selenium, Jenkins CI, Virtualistaion, Linux
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.
We had muscle power!
We had muscle power!
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.