A BZ Media Publication
www.sdtimes.com
February 2014
SD Times
Like the bizzaro world of ‘Seinfeld,’
the two teams look and act similarly but are
more comfortable in their own universes
evOps is about two big worlds
coming together, yadda yadda
yadda. Now you’re deploying
new code every day, right? Not
quite. Just as in “Seinfeld,” when
George’s girlfriend “yadda yadda’d”
shoplifting, those are some big yaddas.
Last month, we covered one of those
yaddas when we discussed configuration-management systems, such as
Chef, Puppet, Ansible, CFEngine and
Salt. Those tools enable developers and
systems operators to deploy fresh code
on fresh systems in an automated fashion, it’s true. But the usage of those
configuration and deployment-management systems covers only one of those
three yaddas.
BY ALEX HANDY
The other two are closely inter-related, and much more managerially driven. One yadda would be agile processes, taken to their logical extremes and
including the operations side of the
puzzle every step of the way.
The other yadda, as it were, would
be unifying the actual medium through
which these processes are expressed.
While developers might keep their
workloads and tasks in JIRA, Rational
or Perforce, the operations side of the
house might stash its tasks within Zendesk, ServiceNow, Zoho, Spiceworks,
or any of a dozen other systems.
And yet, both of these worlds essentially run the same type of software to
accomplish the same types of tasks,
right? It’s like the episode of “Seinfeld”
where Elaine discovers a whole other
group of friends that mirrored Jerry and
the gang: Bizarro Jerry. Bizarro development team has a coffee shop, too!
But do these two parallel gathering
places have the same menu? Can they
both make a Big Salad?
Despite the fact that both of these
virtual coffee shops perform the same
basic functions, they’re not exactly the
same. And even more importantly, it’s
quite difficult to gather everyone up
into a single virtual coffee shop. Just as
you can’t replace a developer with a sys
SD Times
February 2014
www.sdtimes.com
admin, you can’t replace Superman
with Bizarro Superman, nor Kramer
with Bizarro Kramer. So, too, can you
not replace Perforce with ServiceNow,
and vice versa. They’re all much more
comfortable in their own universes.
In fact, best practices would advocate that teams build bridges between
existing systems, rather than provide
one collaborative platform to share.
Kurt Bittner, principal analyst for
application development and delivery
at Forrester Research, said that “It’s
becoming more common to see these
tools tied together. You can’t manage
the life cycle without a common way to
view the work. There isn’t one tool to
rule them all, but this heterogeneous
tool environment is being spanned by
tools like Tasktop, CollabNet and the
like.”
Indeed, a mandate for a single collaborative view of both IT and development is an extremely difficult goal, said
David Jabs, CTO of AccuRev. “I think
this problem’s going to be tough to
solve not because of technical reasons,
but because of organizational reasons,”
he said. “It takes someone above both
operations and development to do it,
and that’s an organizational challenge.”
How DevOps is growing
And just as Bittner said, many companies offer products that bridge the gaps
between social collaboration platforms.
Mik Kersten created the
Eclipse Mylyn project
specifically to tackle this
problem, and it resulted in
the formation of Tasktop
(with Kersten now as its
CEO), a company to
back and sell this
open-source taskbased development
life-cycle tool.
This need for cross-platform integrations comes from the fact
that other areas of the DevOps puzzle
have matured, he said. “The key nut to
crack [for DevOps] was to be able to
deploy continually,” said Kersten. “I
think with DevOps over the last year or
so, that piece has matured. Things like
going from the assets of the applica-
Tasktop bridges the gaps between collaborative tools to provide the same view of a project.
tion—from the design docs and source
code—to things that are built by your
Jenkins, or your CI server. We’ve made
tremendous strides on that layer and
with DevOps.
“The other thing that is interesting
to me is that we’ve already made strides
in the early stages of DevOps. Continuous integration just works now. But of
course there are varying stages of maturity on this front. Some can deploy daily, but at least there is mature automation technology out there from vendors
and in products.”
Because the tools are now mature,
the people and processes behind them
are what require optimization in most
organizations, said Kersten. “On that
side of DevOps, in small organizations,
on the development side.”
And this brings up a major pain
point for DevOps: Those automated
tools and systems can only go as fast as
the teams behind them.
Said Kersten, “So the development
team is using JIRA, the Ops team using
ServiceNow, they’re able to push bits to
production in real time, but the teams
communicate in a biweekly status
update meeting. Does that work?
“I think the first step to getting
DevOps working is that organizations
have to fix that first step. You have to
automate going from source to production and running bits. Once that’s in
place, however, the efficiency gain you
get from that is only as good as your
organization’s ability to learn from
what’s in production.”
Laurence Sweeney, vice president of enterprise transformation for CollabNet,
‘The key nut to crack for DevOps
agreed. “I was talking with
was deploying continually.
some folks in Europe
We’ve made tremendous strides
before Christmas, and they
on that layer with DevOps.’
really do have some great col—Mik Kersten, Tasktop
laboration work,” he said. “They’ve
got lots of people meeting each other;
they’re co-located. But in a fairly small
group—300 people—they have three
you have thinking orchestrated by your different ways to track issues. Even
support desk systems: Zendesk,” he though on the surface they’re collabosaid. “On the other side of Ops, you’ve rating very nicely, they struggle with
got things orchestrated by ITIL systems their schedules, because they struggle
like ServiceNow, which is providing the with islands. It’s a perennial problem in
solution for the Ops people to talk to IT.”
each other the same way JIRA and RalBittner also sees a multi-vendor envily and VersionOne have been successful ronment, and he expects it won’t be
www.sdtimes.com
homogenized any time soon. “Mainly,
everybody’s got these existing workmanagement solutions, and they want to
leverage the value they’re getting out of
that,” he said. “I don’t see an extensive
move toward consolidation of the vendors. Beyond 2014, the work is so similar between these tools, some
gradual consolidation of these
tools is going to happen over
time.”
The odd thing, Bittner
added, is that open source
hasn’t been the driving
force in these collaboration
platforms. “As far as the
open-source tool, it’s been
interesting because the opensource solutions—Bugzilla [and]
other older things—they’ve been superseded by the commercial products. I
don’t see open source coming in and
supplanting major players like Rally
and Atlassian. The other products have
met the needs well enough,” he said.
That means development managers
can now focus on pushing agile even
further into the processes behind
their applications. Randall Newell,
director of capabilities marketing at
IBM, said, “We’re seeing teams moving to agile doing two- or three-week
sprints, with the expectation that the
developer can see immediate results
from their work.”
However, this can be tough for other
teams to keep up with if they’re not on
the same two- to three-week release
cycle. “Consider Cars.com, which has
now gone from doing 20 or 30 releases a
year, to now doing over 400 releases a
year to stay fresh and current. That’s an
agile process that goes very quickly from
development to test to deploy,” said
Newell.
“Contrast that with a much more
complex environment like Nationwide
Insurance. They’re in a regulatory
environment, but they still have moved
a huge portion of their delivery process
to agile. Developers are doing very rapid builds, releasing the build to test
internally, then they go through more
rigid release processes. Developers
need to be able to very rapidly check in
and see the results of their most recent
build and push that into automated
testing as well.”
February 2014
SD Times
important for DevOps, but they’re not
the most important aspect. But I do
believe that even more important are
Addicted to tools
the processes, and maybe even more
Perhaps they’ve met those needs too important is the mindset. In other
well. Said CollabNet’s Sweeney, “If words, the deployment requirements
you’re looking from the bottom up as should be part of the functional
requirements for the application. If you don’t have
that as a part of the
‘Even though on the surface
functional requirements, no collaborathey’re collaborating nicely, they
tion
tool or effort will
struggle with schedules, because
really help you much.”
they struggle with islands.’
David Myers, senior
—Laurence Sweeney, CollabNet
product manager for IBM’s
DevOps team, said, “We actually are
seeing the need for multi-level
requirement management. There are
project managers, we tend to fall in love some functional requirements, some
with our tools. That’s how you end up nonfunctional requirements, some
with three different tracking systems: design requirements: All these tie back
There’s one optimized for testers, one up to the question: ‘What’s the business
for developers, and one for Ops. As reason we’re doing this in the first
practitioners, we have to realize that is place?’ What’s the acceptance criteria
always going to be causing frictional from DevOps? What’s the feedback we
loss and friction in relationships. We’ve get on that in the first place? It’s this virall sat in meetings trying to do a post- tuous cycle between when we’re doing
mortem and said ‘That’s not what my something and finding out what are the
data says.’
customers saying about it.”
“Let people use whatever tools they
Indeed, Landes advocated further
want. You need to say that it doesn’t deep usage of these collaboration tools
matter what tools people use, we’ll beyond their traditional roles. “More
make it work, and we’ll make it work and more, organizations and enterpriswith people. The thing we should do as es understand that their applications
practitioners [is make sure we don’t all that are being developed should be loghave] different data models. The defini- gable [meaning, activities generate logs
tion of what’s the most important thing that can be sent to an external server],
to fix next can differ between the two API-based, and their architecture
teams... Having confusing data models should be such that you don’t need
in standard platforms can be just as bad huge deployments. You have to be able
as having multiple platforms.”
to address specific features, preferably
Igor Landes, vice president of engi- in a pluggable manner. The whole
neering at Exadel, agreed. “Sharing mindset of requirements should go into
the resources between pure develop- the architecture.”
ment teams and maintenance and supPutting the actual system requireport teams is important,” he said. ments for each application into the
“Essentially, if the product has a longer design documentation and tracking syslife cycle and longer releases, some of tem is the key to keeping developers
the people [on each team] do simulta- focused on their application’s requireneously support a production- ments at deployment time, said Landes.
deployed product. They track the use “This is a good process that supports all
of features, bugs and issues, and feed the kind of interaction, and I think it is
that back into the product develop- one of the processes that is being put by
many enterprises into place now.”
ment cycle.”
Still, Landes said that even Exadel
Landes also stated that “tools are
SD Times
February 2014
www.sdtimes.com
keeps development and production-tracking systems separate.
“The reason we keep the things
separately is to minimize the disturbance of the development
team. Usually the production
issues take precedence, or at
least they do if they’re critical. You don’t want to insert
the urgent issue into the development project in JIRA because it
will then impact the velocity,” he said.
“We are tracking the burn-down
rates, and we want to have a predictable
rate of development. We want to have
predictable velocity. If we start inserting the issues into the current sprint for
development, it will impact that.”
Another aspect of DevOps and tools
integration that is growing, according to
Tasktop’s Kersten, is the area of performance monitoring. “We’re seeing some of
our customers asking us to connect the
performance info, connecting in ratings
from app stores and such,” he said.
“In the end, the people doing the
planning have that input, and they’re not
consuming input in the old way with
month-long release cycles. They’re
doing it as part of this two- or threeweek decision process.”
To that end, performance-monitoring systems like New Relic are being
integrated into developer and operations dashboards, allowing everyone to
have the same view on the same information.
and point to the data
sources in the staging
‘Tools are important for DevOps,
environment. Then
but not the most important.
you can run the
scripts kind of in
Even more important are processes,
production.”
and maybe even more important
IBM’s Newell said
is the mindset.‘
that the heart of all these
—Igor Landes, Exadel
process is “collaboration. We tend
to look at DevOps as more than tools
integration. It’s about culture and
process and tools. What can a manager
do? What we’ve seen, especially among
What are the fundamentals?
Landes pointed out the fundamentals our larger clients moving from or who
for developers as an enabler for have moved from waterfall to agile,
DevOps. “There are other things that they’re physically encouraging better
are interesting that have a very pro- collaboration by staffing teams that
found impact on this DevOps unity, if include business and infrastructure
you will,” he said. “Unit tests, for exam- skills as well as developers, and they
ple. What relationship does this have to rotate the leadership through the team.
DevOps? If you write your unit tests in They’ve impacted the physical location
a way that they can be executed in any by locating these teams together in
environment, then when you deploy or open pods encouraging integrations.”
Of course, all of these processes
if you have an issue in production, you
can run the selective unit tests for the require you, the manager, to actually
area under suspicion. In this way you implement them. If your office is filled
with a gang of Newmans and Kramers,
can find issues easier.
“If you have test automation for your with their Bizarro equivalents in Ops,
regular development life cycle, you can you might be better off sleeping under
write these test cases and scripts in a way your desk. But if you can turn those
that they can be applied to a production wacky neighbors into one big happy
environment. It’s not trivial...but then it family, you might just Read this story on
sdtimes.com
be able to push
becomes much easier to troubleshoot.
“You don’t want to mess with the through some major
data in production environments, but if process changes at
you do it properly, you can, for exam- your own private Vanple, switch data sources in production, delay Industries. z
Reprinted with permission from BZ Media.
CollabNet® is the creator of Subversion® and a pioneer in cloud-based
Application Lifecycle Management (ALM) solutions for collaborative agile
software delivery at scale. CollabNet provides industry-leading products
plus agile consulting and training services to help organizations of all
sizes develop and deploy software faster.www.collab.net.