My Journey in to DevOps
Part 1: Development Discipline
The Development Discipline is very basic. Developers make sure that their codes have a proper Test and Version Control System.
Test-Driven Development and Unit Testing
Know how to fail and know how to succeed.
TDD is a development technique where you must first write a test that fails before you write the code, while Unit Test is the script you create to help realize the TDD philosophy.
- Test: A plus B must equal to 3
- The result of this test will be False since the values for A and B are Unknown.
- Function: Let A be equal to 1 and B be 2
- The result will be True, and the test will pass.
This process makes sure that each Unit of the application works as expected.
A perfect Member or Unit is useless if it does not play well with the Team.
Functional Tests test the software by feeding them input based on business requirements and application specification and then examining the acceptability of the output.
Tests usually happen in System and Acceptance Testing. It just makes sure that the whole application works as expected.
Git Flow usually utilizes four main branches.
The Develop Branch
Also known as Feature Branches
These are the flexible and fun parts of the tree. They are named feature/[name]
The Release Branch
These are a tested set of feature branches ready to be promoted for production. They are named release/[version]
Read more about Semantic Versioning.
Read more about Semantic Versioning.
The Master Branch
Also known as the Trunk. The master is the latest and working version of the source. Release Branches will merge into the Develop and Master Branches. Then the Trunk gets tagged with the Release's Version Name.
The Hotfix Branch
These are the updates that, ideally, do not need any more testing.
The developer will branch out from the Master Branch.
Then, the Developers will add the updated code.
Finally, it will merge into the Develop and the Master Branches.
Hotfixes must not exist for long to prevent further conflicts.
Note that Severe Bugs require tests.
Trunk Based Development
The simpler approach. Trunk Based Development utilizes a single Master branch with short-lived Feature Branches.
Start-up teams who iterate quickly and are mostly made up of Senior Developers benefit best from this approach.
However, Large scale projects might require a far more complicated approach than Trunk Based Development.
Part 2: Provisioning and Configuration
Infrastructure as Code and Configuration
A complicated idea can be understandable if divided into small pieces.
It is the way of managing and provisioning computer data centers through machine-readable definition files instead of physical hardware configuration or interactive configuration tools.
Managing your infrastructure as a software can give you the flexibility of the Software Development Life Cycle (SDLC). Having SDLC makes it easier to provision different environments of the infrastructure. IAC in Automation Pipelines is a powerful solution for automated infrastructure provisioning.
Software Configuration and Management
Software Configuration or Management tools come hand in hand with IAC.
It prepares the provisioned infrastructure and deploys the required software for the intended application to run. It can also be done automatically via an Automation Pipeline.
GitOps is an approach for cloud-native applications that focuses on having a developer-centric experience when configuring and provisioning infrastructure using tools similar to Git and CI/CD tools.
Part 3: Automation
Automation is the heart of DevOps.
Be Lazy while being Productive.
Lazy, for I don't have to trigger the test scripts every time I need to. And Productive, as I will be creating a manageable automation script.
Speed, velocity, and ease for the client teams rely heavily on automation.
An organization must define what tasks should be automatic or manual, when should the job be triggered, and where should it be situated.
Infrastructure Provisioning and Platform Configuration, as well as Source Code Version Control, can be Automated.
Part 4: Automation Pipeline
DevOps won't be complete without CICD.
Always compile and test your work regularly and automatically.
A Developer will commit all his work in his feature branch. Each check-in will then be verified by a Build, which allows teams to detect and solve problems immediately.
Before publishing something, make sure everything is working.
Continuous Delivery, unlike Continuous Deployment, requires the release approval from a team leader before finally publishing the version into the production.
Speed is a highly effective double-edged sword.
Approval for production is not required. You get your order once it's done, like fast-food.
It relies on the well-laid plan of a Test Strategist ™.
The features will run on multiple automated tests on different stages with all the possible scenarios. If all tests pass, the feature will be merged directly into production to be immediately consumed by the end-user.
The key players here are the test scripts and scenarios.
Know everything that your project is doing.
The forgotten sibling. Always last, sometimes missing.
Monitoring can be a simple display of metrics and statuses of Servers and Pipelines, or a complex feedback system using webhooks and alerts.
Traces and Logs should be collected, manipulated, and sent as a useful, human-readable report.
All DevOps Practitioners must implement this at all costs.
- Implement Proper Testing Protocols
- Tests can be automated
- It gives assurance to the application
- Continuous Integration
- Continuous Delivery
- Continuous Deployment
- Enforce security policies on every part of your process
The proper use of these components is the priority of a DevOps practitioner. Continuous Communications between departments and teams must always be a priority.
DevOps Practitioners must continue to share and evolve the culture.
This article barely scratches the surface of DevOps. As I continue this path, I will undoubtedly learn more about the culture and its community. And I look forward to it every day.