Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Opinionated DevOops

August 08, 2018

Opinionated DevOops

An opinionated talk I gave to my client team about devops practices.


August 08, 2018

More Decks by Naren

Other Decks in Programming


  1. WHAT IS DEVOPS ? DevOps is the combination of cultural

    philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity: evolving and improving products at a faster pace than organizations using traditional software development and infrastructure management processes. This speed enables organizations to better serve their customers and compete more effectively in the market.
 - AWS
  2. 2009’S Velocity Conf 10 Deploys Per Day, Dev & Ops

    cooperation at Flickr John Allspaw & Paul Hammond
  3. PHILOSOPHIES Work together to optimize both the productivity of developers

    and the reliability of operations Increased communication Full ownership
  4. CONTINUOUS INTEGRATION Regularly merge their code changes into a central

    repository Find and address bugs quicker and improve software quality Reduce the time it takes to validate and release new software updates.
  5. CONTINUOUS DELIVERY Code changes are automatically built, tested, and prepared

    for a release to production Deploy changes to testing or staging or production environment Developers will always have a deployment-ready build artifact that has passed through all testing process
  6. MICROSERVICES Each service is scoped to a single purpose Runs

    in its own process and communicates with other services through a well-defined interface (HTTP, GRPC, Queues) Deployed independently or grouped with similar services
  7. INFRA AS CODE Infrastructure is provisioned and managed using code

    and software development techniques Treat infrastructures like application code Since it’s like code, it can be deployed with standard patterns, updated with latest versions and patches
  8. MONITORING AND LOGGING Monitor metrics and logs to see how

    application and infrastructure performance impacts end user experience Alerts and continuous monitoring helps to respond to incidents effectively Gives a continuous feedback to evolve business logic
  9. COMMUNICATION AND COLLABORATION The tooling and workflows brings the team

    together to deliver features Use of chat, issue tracker and wikis speeds up the communication among devs Makes other teams like sales and marketing to align more closely on goals and projects
  10. FEATURE PLANNING 5 days or 10 days sprints in JIRA

    Break down the features into achievable chunks End of every sprint cycle release a version of the software
  11. GUIDELINES Git should always have two branches: master and dev

    Develop in master branch until initial PoC is done (Where the idea is not an hypothesis anymore) Lock the ‘master' branch. Start a ‘dev’ branch
  12. GUIDELINES (CONTD.) Pick a feature from current sprint (JIRA), branch

    out a ‘feature’ branch from ‘dev’ branch. After implementing one of the feature, write unit test cases and merge it back to ‘dev’ branch. Then, delete the ‘feature’ branch. Our CI system kicks off as code is pushed to ‘dev', runs tests and deploys it in the dev server(?) Once all the features for the currents sprint are done, After a quick code review we merge dev to master. The CI system will kick off, builds and deploys the code pushed to master in prod machines Repeat the steps for every sprint in JIRA
  13. GUIDELINES (CONTD.) After initial development, note that the master branch

    will always be locked, one cannot directly work on master branch. You can work by only branching out. The tip of the master will always be the latest, stable, production release. Refer Semantic Versioning for versioning your releases: 
  14. GUIDELINES (CONTD.) Tagging the releases helps us to quickly rollback

    prod systems. If an unknown bug makes v0.2 unstable, we can quickly rollback to v0.1while fixing bug in v0.2. 
 When rolled back client may lose the new features of v0.2 but they won’t experience total downtime as it’s rolled back to working version v0.1.
 Once bug in v0.2 is fixed, it's deployed again
  15. Time master dev feature branches New feature in computer vision

    Tag v0.2.0 New feature in API and DB Tag v0.0.1 (Lock Master branch) Tag v0.1.1 Tag v0.2.1 Work on master branch until a very basic MVP is done

  16. TESTING Write unit test cases for the code before merging

    to ‘dev’ from ‘feature' branch Unit test cases helps us to check the sanity of every function in the code. So, any function in the code should have only one responsibility. Unit test cases are important while setting up CI/CD. Since every feature is continuously deployed by the system, code should be well tested before pushing to master branch
  17. LOGGING When a piece of code is written, it should

    provide some way to give the insights while running A very simple way to do it is having a basic logging system dumping logs to files. In future we will see how we can create a dedicated logging mircorservice that collects logs from other services and provide application and business insights.