CCF Archive Site

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

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.

@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.

If you work with companies < 100 people, you won't see DevOps, and if you do, it's someone trying to pad their resume and spend the owner's money. If you work on minimum viable products for startups you'll never, ever see DevOps, just (hopefully) decently integrated test and source control.
...

If too small a business talks up DevOps, they are blowing hot air and trying to be trendy. They just won't have the scale to pay someone to be a source control maven as a separate task from writing code.

It might depend more on the size and complexity of the code base rather than the number of developers.   In my last (government contract) job there was a big code base that had been repurposed for another project.  I felt that Subversion and Jenkins worked great for continuous integration and I was grateful to have the tools. There were maybe 10 active developers on the project.

I think the guy who was managing Subversion and Jenkins was part of the development group.  Some developers would do anything to get away from software maintenance.

Sun (now Oracle) has (or had) an automated deployment tool called JumpStart.  Not sure where the deployments were -- whether it was in house or in the field.  The guy who was using it was a developer (no doubt doing anything but software maintenance) and he may have been padding his resume, but work was pretty tightly managed so he would have had to have shown results that were worth his cost.

It's a different subject, but virtualization is something else that pertains to software automation. It's almost the ultimate way to automate away the costs of humans managing hardware resources.  Maybe this is why we find a discussion of DevOps on the virtualization site I've mentioned.

It might depend more on the size and complexity of the code base rather than the number of developers.   

IMO (and actual experience with a variety of clients) it all .... every bit of it... comes down to money.

You cite 10 developers and for me that's actually a fairly high number in my experience. Most groups I've been a part of had no more than 5 people working on any one thing as developers.

Size and complexity of the code base could be a factor, but a lot of businesses own legacy code that is well beyond their current budget to handle its technical debt.

I believe you have to hit a certain budget level and also awareness level in an organization in order for the org to justify DevOps. Which very strictly speaking is overhead. Like documentation.

I think the guy who was managing Subversion and Jenkins was part of the development group.  Some developers would do anything to get away from software maintenance.

Now that IS a really good new point. Yes, I see what you mean.

It's a different subject, but virtualization is something else that pertains to software automation. It's almost the ultimate way to automate away the costs of humans managing hardware resources.  Maybe this is why we find a discussion of DevOps on the virtualization site I've mentioned.

Now, Virtualization is something *you* can experiment and tinker with right now and learn about as much as someone currently working.

Download and install a copy of VirtualBox, the most prevalent virtual machine package. It can run well on an Intel i-class with 8 GB ram and up.

With virtualization, a key point is that an entire computer's image - the OS plus all of its current state and all installed programs and data - resides on one perhaps very large "virtual hard disk" file. An entire machine's worth of setup and current state can be saved in one massive file, stored, backed up, versioned....

With virtualization, a key point is that an entire computer's image - the OS plus all of its current state and all installed programs and data - resides on one perhaps very large "virtual hard disk" file. An entire machine's worth of setup and current state can be saved in one massive file, stored, backed up, versioned....

Right.  That's why I say this is the ultimate in deployment automation.  You just replace the old machine file with a new one.

Ok. That's a good explanation.

As a general topic of discussion, DevOps is some currently in-demand technology among many others (e.g. InfoSec) which a person could potentially learn about.  Is psxant right?  Can an older worker turn their attention to something they've never before been employed to do and get a job doing it?

That's one place I disagree. From what I'm reading, DevOps appears to be a management technique. As well as a stack of particular tools.

The way the support activities such as source control, testing, documentation, deployment and builds are managed is DevOps.

Yeah, the ones who work in DevOps will consider it a skill set, but as far as what I've read it's more like a methodology.

And if it's a management technique, you really can't get any credibility with self-learning (which is hard enough as it is with self learning for a strictly technical skill.) Employers will want to really know that you've actually done it on a paid career basis.

Perhaps your take is different?

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.

Everything you wrote is dead on. Agile blows. We do it where I am now but I changed it to only quasi-agile. The daily standups were hated by everyone so I stopped doing it. We only have like 2 meetings per week and I let the developers decide what they want in each sprint. I work in a very highly regulated environment so I had to overlay waterfall on top of agile due to the regulatory requirements. It was tough in the beginning but we run pretty smooth now. Full blow agile though? NO THANKS. Agile is basically about micro management of the developers and everyone else.

When I did financial services Devops was a combination of development and production support. I have not seen Devops in other industries outside of financial services. Its a nightmare from what I saw. Basically the developers were expected to code and be production support monkeys simultaneously. Most didnt last long because the stress was totally out of control. Picture trying to code and at the same time they are up your butt about some production problem. You cant focus and you have people breathing down your neck all the time. This is why I stopped coding.

I have noticed that each industry has seized on their own sets of lingo and development nonsense. For example when I did financial services they were totally jacked on ITIL. I had never heard of ITIL prior to this. It definitely wasnt used in telecom or DoD. Not in the work I did anyway. And like most of these methodologies ITIL BLOWS. I have seen Six Sigma in more than a few companies but it usually doesnt filter down to far because again its one of those things that only makes sense in certain situations.