DevOps and Me!

DevOps = (Dev)lopment + (Op)eration(s)

I definitely seek for opportunities where I could add challenges and newness at my workplace, and these all can start from myself and assignments are given to me.
I got to interact with one new culture in IT World i.e. DevOps. DevOps that says to work in a collaborative manner. For Developer like me I have to collaborate with other teams say Operation Teams, I would like to include Testing Teams, Downstream and Upstream Teams, and all other teams will come across my work right from the instance the task requirement was founded to the instance implementation of task requirement will be utilized.
I should understand I don’t have longer timelines for collaboration and my own assignment, so this should naturally reflect in work style. It should be so obvious to your monitoring guys that yes, it is required to do so.
When I read about DevOps, I mostly went through its glossary and it taught me, explained me and made me to understood how the quality of work can be increased many times if I keep this glossary and its meaning clear in my mind.
Continuous Delivery, Continuous Integration, Release, Deploy and other n terms. Continuous Delivery prescribed me straightforward that deliver a fully working and tested software or changes or application or any else thing going into production through me. It shouldn’t have a bug, to which everyone fears. Simply, I don’t need to deliver a huge chunk of code into Production, I need to deliver code one by one, in a small amount, and in an incremental way. The question comes how I can ensure that small amount of code is also digestible to Production, it should accept the new changes from the system perspective, end-user perspective. There are more chances things definitely work elsewhere except Production. So Continuous Integration is there.
What I understood from this Continuous Integration term, it is highly like what traditionally IT Industry is following that don’t leave any bug in the system before sending it into Production. How it is different then? Well integration of various tools that help to capture system bug, resolve, repeat the exercise, and say “Done”.
Release and Deploy terms are not just for your zone, your environment it is about elsewhere your changes are going, starting from Development, then Integration, Staging, and ending on Production. You are equally stakeholder for your code at every stage of deployment.
Now maybe a question what if I have DevOps in my mind, but my projects, my assignments don’t. Well, with what I understood and accepted. This should be a natural approach in work style. Let’s read the definition of DevOps:

DevOps is a software engineering culture and practice that aims at unifying software development (Dev) and software operation (Ops).
The main characteristic of the DevOps movement is to strongly advocate automation and monitoring at all steps of software construction, from integration, testing, releasing to deployment and infrastructure management. DevOps aims at shorter development cycles, increased deployment frequency, more dependable releases, in close alignment with business objectives.

This is just a brief understanding of DevOps culture and its connection with traditional workstyle that needs a definite upgrade in dynamic IT world.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Create a website or blog at

Up ↑

%d bloggers like this: