Main Category > FTE, Job and Career Discussion

What is DevOps?

(1/4) > >>

I D Shukhov:
It has a Wikipedia definition, but I was wondering if anyone has actually done that kind of work or is thinking about doing it.

In my last position, which is becoming a distant memory, we checked software out of a version control system named Subversion (which in today's world is probably Git) and when we checked it in everything related to the  file(s) got built with Hudson, which is now called Jenkins.

There was quite a bit of work done with automated testing also, although I didn't always have the time to keep the automated tests up to date.

I think that is an example of DevOps:  automated builds, version control and tests all bundled together in software development.

This may be enlightening:  https://virtualizationreview.com/articles/2016/07/06/3-devops-tools-you-should-start-with.aspx

The Gorn:
Good topic.

You have DevOps right, I think.

When I see DevOps I think of more extreme role specialization.  10 years ago the developers themselves would select and configure the source control system. Today it's done as a separate business function.

The "problem" with that in business-speak being that the developers don't have the high-and-mighty comprehension of the entire business.

I think of "DevOps" as a separate team or business function that makes infrastructure stuff happen for developers. And presumably is wiser and less benighted than the lowly programmers. Or something like that.

I used Subversion a *lot* in the 2003-2010 time frame. Yes, Git seems to have replaced it.

The Gorn:
Also, I just skimmed the Wikipedia article. There is much more to that coined term than what I thought.

Reading that article makes me think "my God, how could I possibly ever fit into a software development job again?"

The answer to that being smaller businesses and work that doesn't touch the enterprise level. Otherwise if you want to work in the big leagues you have to understand and grok this stuff. I do, but I don't want to.

pxsant:
It looks like just another spin on agile development.   I have been in agile shops and it is the most overrated methodology I have ever seen.  Rather than making development times shorter, agile makes a complete mess of the development cycle.  Many more people are involved than need to be so the cost skyrockets instead of going down.

Another aspect of agile is the daily standups.   What a complete waste of time.  Far too many meetings.   They prevent a developer from getting into a productive zone where most of the actual work gets done.

The bank I am consulting at right now has chosen the biggest project they have ever done to go agile.   And nobody has real experience in the agile methodology.   The agile output that they hand to developers will be a steaming pile of crap.    The developers will throw it in the trash and ask for actual specifications they can use.

Ultimately this project has a good chance of getting canceled because of their inability to get any actual work done.

Agile, including Devops, might work on small projects but it definitely has severe limitations.

I D Shukhov:
@Gorn

I think you're right about big software engineering shops having a specialization of labor where some group is in charge of the CM, build and delivery automation.  I wonder where these people come from?  Are they ex-sysadmin types or ex-developers? 

I think developers *have* to take an interest because when I see job specs on Indeed I'm seeing having to have Git experience and such things as Puppet and Chef, which I think are used to automate deployments.   I've never worked somewhere where software was deployed all over the place.  It's probably an interesting subject.  I remember that UML has a https://en.wikipedia.org/wiki/Deployment_diagram which models how software gets deployed to where it's going to be used.   Software could get deployed to either physical or virtual computers.   Hosting companies and cloud services would be deeply concerned about this problem.

The goal of DevOps is to ferret out anything that is getting manually and repetitively done and automate it.   This is a perfect example of how automation is going to affect jobs.  Boring, tedious work will go away, along with the people who used to do it -- in this case individual programmers or sysadmins who had specialized knowledge about aspects of the SDLC crucial to the organization and it will be done by DevOps tools.  New jobs are created for those who can use the DevOps tools.

@psxant

Things never change do they?  Back in the day, long before the word "Agile" had been invented I used to go to daily "merge meetings" where you had to explain what and why you were merging into the baseline. "Breaking the build" was about the most humiliating thing a programmer could do.  Continuous integration solves that problem nicely.   It's like balancing your checking account a couple of times a week online vs. balancing it monthly.

Agile, and all it implies, tries to solve communication problems within a software shop. The hierarchical model I used to work in started with design meetings and design documents generated and then task groups would go implement their parts.  A CM group would build everything and a testing group would test it.  Then it would get deployed in the field somewhere by some other group who would report back from the field.   

Software is such a marvelous productivity and cost savings gain for organizations, compared to all that is manual, that all the things that can and do go wrong with producing it more than makes up for what it accomplishes.

I think while DevOps tries to handle improved quality of software production by automating wherever it can, Agile human interaction reengineering tries to improve the quality of communications.

Have you seen companies using message boards for asynchronous communicating instead of stand-up meetings?  Just like continuous integration, it seems like a message board would be better for continuous communicating.  You could have a forum for each group and an integration and test forum.  All these forums would be public in order to have total transparency to all throughout the organization.  The messages could link to discrepancy reports, build status, the "Log visualization and analysis" (whatever that is) mentioned in https://virtualizationreview.com/articles/2016/07/06/3-devops-tools-you-should-start-with.aspx.   I'm pretty sure open source projects do this as the work is geographically distributed.


Navigation

[0] Message Index

[#] Next page

Go to full version