An opinionated talk I gave to my client team about devops practices.
WHO AM I ?
Senior Software Consultant
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.
WHAT IS DEVOPS ?
HOW WAS IT BORN ?
Months or Years
Weeks or Months
DEV (VS) OPS
NOT MY PROBLEM
IT’S EVERYONE’S PROBLEM
10 Deploys Per Day, Dev & Ops cooperation at Flickr
John Allspaw & Paul Hammond
Hours or Days
THE DEVOPS MOVEMENT STARTED
Work together to optimize both the productivity of developers and
the reliability of operations
Infrastructure as Code
Monitoring and Logging
Communication and Collaboration
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.
Code changes are automatically built, tested, and prepared for a release
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
Each service is scoped to a single purpose
Runs in its own process and communicates with other services through
a well-deﬁned interface (HTTP, GRPC, Queues)
Deployed independently or grouped with similar services
INFRA AS CODE
Infrastructure is provisioned and managed using code and software
Treat infrastructures like application code
Since it’s like code, it can be deployed with standard patterns, updated
with latest versions and patches
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
Gives a continuous feedback to evolve business logic
COMMUNICATION AND COLLABORATION
The tooling and workﬂows brings the team together to deliver features
Use of chat, issue tracker and wikis speeds up the communication
Makes other teams like sales and marketing to align more closely on
goals and projects
Apache Mesos with Marathon
AWS Cloud Watch
BRINGING IN THE DEVOPS CULTURES AND
To Be Continued…
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
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
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
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,
Refer Semantic Versioning for versioning your releases:
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
ﬁxing 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
Once bug in v0.2 is ﬁxed, it's deployed again
New feature in
in API and
(Lock Master branch)
Work on master
branch until a very
basic MVP is done
Write unit test cases for the code before merging to ‘dev’ from ‘feature'
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
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
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.