Slide 1

Slide 1 text


Slide 2

Slide 2 text

WHO AM I ? Naren Senior Software Consultant Tarka Labs

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

Philosophies Practices Tools WHAT IS DEVOPS ?

Slide 5

Slide 5 text


Slide 6

Slide 6 text

PRE-2000’S Business Dev QA Ops Friction Friction Friction Customer Release Cycles:
 Months or Years Idea

Slide 7

Slide 7 text

2000’S Business Dev QA Ops Friction Customer Release Cycles:
 Weeks or Months Agile Idea

Slide 8

Slide 8 text


Slide 9

Slide 9 text


Slide 10

Slide 10 text


Slide 11

Slide 11 text

2009’S Velocity Conf 10 Deploys Per Day, Dev & Ops cooperation at Flickr John Allspaw & Paul Hammond

Slide 12

Slide 12 text


Slide 13

Slide 13 text

2010’S Business Dev Ops Customer Release Cycles:
 Hours or Days Lean Idea DevOps

Slide 14

Slide 14 text


Slide 15

Slide 15 text

PHILOSOPHIES Work together to optimize both the productivity of developers and the reliability of operations Increased communication Full ownership

Slide 16

Slide 16 text

PRACTICES Continuous Integration Continuous Delivery Microservices Infrastructure as Code Monitoring and Logging Communication and Collaboration

Slide 17

Slide 17 text

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.

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text


Slide 24

Slide 24 text


Slide 25

Slide 25 text

CI/CD Concurse Jenkins GoCD Gitlab CI Circle CI Travis CI Complex/Enterprise Simple

Slide 26

Slide 26 text

DEPLOYMENT Chef Puppet Terraform SaltStack Ansible

Slide 27

Slide 27 text

SERVICE DISCOVERY Zookeeper Consul EtcD Complex/Enterprise Simple

Slide 28

Slide 28 text

ORCHESTRATION Kubernetes Apache Mesos with Marathon AWS ECS/Fargate Complex/Enterprise Simple

Slide 29

Slide 29 text

MONITORING Nagios Prometheus Icinga New Relic AWS Cloud Watch

Slide 30

Slide 30 text

No content

Slide 31

Slide 31 text


Slide 32

Slide 32 text

To Be Continued…

Slide 33

Slide 33 text

No content

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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:

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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.

Slide 42

Slide 42 text

Naren @DudeWhocode