Comment by Sébastien Portebois on "How do you explain devops in simple terms?"

CommentHow do you explain devops in simple terms?

Sébastien Portebois

Software architect at Ubisoft

Dec 29, 2015

The simplest way I can imagine is : « you have to maintain what you developed », or, «you have to make sure that the component you developed runs correctly in from the dev stack to the production stack, and all the intermediate stages » All the other parts are direct consequences: - the engineer as to be aware of the infrastructure components, he has to understand it correctly - pushing/updating updates should not require complex sysadmin skills (ie automation and abstraction of some plumbing is helpful)

This implies smaller dev cycles, smaller updates, easier to deploy. The container (Docker-related) paradigm shift is also very helpful to separate the concerns: once the infrastructure foundations are set (permissions, ...), updating/adding a service should no longer require advanced infrastructure skills.

This is a "from the top of my head" description and I'm pretty confident you'd find better answer on internet, but - from my point of view - the most important point is that mentality shift, where the software engineer is no longer conflicting with the sysadmin team, but rather mixing the skills and collaborating to manage his development in its whole lifecycle (from dev to running in prod, and handling the issues)

Benny A

Web and Mobile app Development expert

Feb 3, 2017

Is there a "type of project" or "size of project" limitation to consider DevOps? or Even small web apps can adapt DevOps?

Well I don't think so. The processes you'll build and use will change depending on the size, but not the goals. Now that I read this old description, I think I could have written something more 'meta': Devops is the set of processes (including tools) you'll use to achieve one single goal: being able to release your project in a fast and reliable way. The means to reach this goal are all the usual considerations that come with devops: be really serious with all the automated tests, use CI, consider CD - and try to use it if you meet the requirements, automate as much as possible to reduce all the delays between idea, implementation and release to the audience.

Thinks of it like:

waterfall was one project was 1 big iteration with one final release.
agile (and especially scrums and sprints) was splitting that in many smaller iterations, each each small milestones (I liked it, but it was nothing more than a way to split waterfall in many smaller pieces to adjust along the way)
devops is trying to reduce these iterations even more. All the engineering and cultural aspect coming with devops are means to reach that goal.

So back to your question: even a super small project could adopt the devops approach: if you want to release/deploy it in an automated fashion, you'll need the automation (of builds, tests, checks, ...) that comes with devops, even for a single-person project. (Although they will be much easier to setup given the smaller size) Does this make sense?

Search Hashnode