I recently participated in a discussion in the Configuration and Release Management forum in LinkedIn. A person asked a straightforward question about Git. I was a little surprised to discover significant resistance to Git from the senior build engineers and release managers on the forum. They weren't just speaking religiously either; they had facts to back up their information, including:

• Git lets you meddle with the past and delete arbitrary revisions
• You can't tell by looking at a particular commit what its relationship to previous and future commits is
• Auditing and controls are difficult to impossible, which are especially relevant issues for public companies or companies facing acquisition

The concensus among the engineers in operations was that developers don't care what happens once code leaves their hands. 

As a person from a developer's background, I bristled a bit at that. However, thinking back, it's true. We want bug-free code, but we don't really spend a lot of time thinking about QA, build, and release unless someone makes us. Release engineers roll their eyes when they see developers coming, bundles of optimism, buggy code, and new dependencies that change the build process.

This is one reason why Agile, properly done, is great. Most people think Agile is just a way to help developers ship code faster. At its heart, though, Agile is a communication-based methodology that spans the entire life cycle. Don't understand a requirement? Ask the author. Need testing done? Get a tester involved as soon as the feature is ready. Need to release some code? Have a process to get validated code to the release engineer, and make sure they're in the meeting.  

At ProjectLocker, we have historically viewed our customer as the software developer. Our real customer, though, is the software development organization, specifically the Technology Management Office. That means that our ability to help our customer succeed is governed by our ability to help the organization collaborate. That's why we've focused on features ranging from an activity stream to let managers see the "pulse" of a project in-progress to our actual Pulse product, which does live application exception reporting. Better software, tracked in a collaborative platform like ProjectLocker, is both easier to release and easier to police, which should make the job of the Operations team easier.

Our free white paper covers more on how our tools best fit into the configuration management plans of a software organization. You can learn more bly clicking the button below.

What do you think? Is Operations a drag on rapid development or a necessary part of a successful software process? How can we better assist developers and release/delivery personnel in seeing eye to eye?

Image Credit: reynermedia
Licensed under Creative Commons Attribution 2.0 License