What is DevOps?

DevOps can be a lot of different things depending on the context - a methodology, a culture, a set of tools, a department or job title…

The purest definition of DevOps is a culture of collaboration between Development and Operations (and really, every other department in the company). In a traditional workflow, you have a product team that comes up with a product. They brainstorm features, do design, etc. Once that is done they will pass off that work to development. The development team will take that, spin up local development environments and then implement all the features/design/specs/etc they got from product. At this point, it’s lobbed over the fence to QA, who has to create all the testing plans and such in a hurry (and then of course actually DO the testing), because at this point development is ‘done’, and the company is breathing down their necks to get the product released. After the code is kicked back and forth a few times with defects, it will eventually show up on operations’ doorstep. Operations has to figure out what infrastructure is required, as well as how to deploy, run, and scale this code. And again, this time likely has not been well-budgeted for.

Does this sound terrible? Enter DevOps!

There should no longer be ‘siloed’ departments where work is shuffled between teams that do not communicate. All these teams should be working with each other from the very beginning to ensure the process is streamlined and efficient. In the end this will create code and infrastructure that is stable, scalable, and maintainable.

Aside from this cultural shift, DevOps tends to bring specific tooling and methodology with it. Things like version control, continuous delivery, infrastructure as code, configuration management, communication and collaboration, automated testing, etc. These tools and practices will help streamline the feedback loop and allow features to become reality.

Generally this is all accomplished by creating cross-functional teams that work on specific products. You will have product, development, operations, qa, etc all acting as one team with shared processes for work (commonly agile, with sprints and scrum). Any ‘story’ that comes through will be touched by multiple members of this team, who will work together to ensure all areas are accounted for. This story will not be considered ‘done’ until it has reached production successfully.

So just remember: DevOps is all about removing barriers between teams to increase efficiency. At the most basic level, that should be your focus when deciding to implement any specific tooling, processes, or methodologies within your company.

 
0
Kudos
 
0
Kudos

Now read this

Managing local password policy with `pwpolicy`

Have you ever wanted to enforce password policies on local OS X users? Things like complexity, expiration, rotation, etc? Well you are in luck! On OS X, users are managed in a local Directory Service, and so you have the same tools on... Continue →