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
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.
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
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
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
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
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
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
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
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
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: https://semver.org/
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
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
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
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.
dudewhocode
m_coder
jrsaruo
shimabox
hschwentner
shibe23
kin29
hirodragon112
ivargrimstad
ogiwarat
iwatatomoya
stanby_inc
jnunemaker
garrettdimon
maggiecrowley
searls
rocio
cherdarchuk
kneath
keavy
edds
revolveconf
malarkey
wjessup