This content is part of the Essential Guide: Use these DevOps examples to reimagine an IT organization

IT regulatory compliance throws a wrench into DevOps gears

Outdated compliance rules can mean automated deployment runs right up to the edge of the production environment -- and then comes to a screeching halt.

IT regulatory compliance measures sometimes clash with the automation ideals of DevOps.

Ideally, compliance is folded into the highly automated DevOps process, as it is at companies like Wayfair LLC, an e-commerce furniture company in Boston. At Wayfair, regulatory compliance strictures are just part of the workflow: Each change to application code is treated as relevant for compliance auditing purposes, logged and signed off on electronically. The company makes 100 to 200 changes per day across its environment, and this level of compliance automation is necessary to achieve such frequent updates.

Wayfair uses a combination of mostly open source tools for logging, including an ELK stack (ElasticSearch, Logstash and Kibana).

"Most auditors are comfortable with logs," according to Chris McCoy, manager of the production systems team at Wayfair.

Also, ideally, IT regulatory compliance measures are incorporated into the automated testing of code before it's pushed to production.

"All of a sudden, you have much more rigor about what your approval process is, you've documented it, you've agreed upon it and it's in your source code management system," said Gary Gruver, an IT consultant and founder of Gruver Consulting LLC in Sun Valley, Idaho.

Incorporating compliance tests into the company's main source code management system, such as Git, also can ensure those tests remain consistent and document changes made to them over time.

When it comes to the auditing process, auditors are concerned about whether processes and procedures were consistently followed and documented, Gruver said. Using a source control management system, rather than a manual approval process, ensures compliance controls are adhered to every time code is tested and pushed to production.

Reality does not always reflect the ideal

While codified compliance is the ideal in a highly automated environment, it's often a challenge to get there.

At many large enterprises, code is automatically tested and integrated, and deployed through a development pipeline that is highly automated and spans development, quality assurance, testing and staging environments. However, when it comes time to push to production, all that automation comes to a halt and someone must manually push the button to invoke the production stage of code delivery.

Under some IT regulatory compliance strictures, "you can't have a developer [who] was involved in the development of code pushing that to a production environment -- there has to be some separation [of roles] there," said John Gildenzoph, DevOps engineer for Total Administrative Services Corp., a third-party benefits administration firm in Madison, Wis.

Automated may not even be the best term for the push to production, according to Chris Lawther, data architect for a Fortune 50 company based in the Northeast. "One-click release is a better term to describe it," he said.

Experiences with auditors also vary widely among enterprises.

"I haven't seen one yet that wants to get into the code level," said Daniel MacDonald, architect and principal technical lead for a New York agency that's working to adopt Agile software development techniques.

A question of culture and corporate policy

For IT regulatory compliance with certain laws, such as the Sarbanes-Oxley Act of 2002, corporate policies can be sticky and difficult to change, according to Don Luchini, a senior software engineer for an energy management software maker in the Northeast.

"The rules that we have in place predate our use of the word DevOps, they predate our use of AWS, and the last time that we changed them was probably over five years ago," Luchini said. "They were written for a very different application platform at a very different time in the company's history."

Thus, the processes for documenting changes and separation of roles mandated under Sarbanes-Oxley is "grafted" onto the DevOps process, resulting in production change tickets that "all look exactly the same," Luchini said.

There is an incremental step that can be taken to automate the creation of those tickets, even if they need to remain in place, according to Luchini.

"There is room there for automation," he said. "While we're not in the short term looking forward to full automation, there are little manual bits that are ripe for the taking."

Processes like this fall within the cultural change that needs to take place along with tooling as enterprises embrace DevOps, according to Gartner analyst George Spafford.

Some of the corporate rules that have been adopted by enterprises are based on common misconceptions of what laws actually require, Spafford said. Part of embracing DevOps is to question those policies and rules, and whether they are strictly necessary.

"You have to just unrelentingly question, 'Why are we doing this?'" Spafford said. "What is the risk that we're trying to mitigate -- and is there a better way?"

Beth Pariseau is senior news writer for TechTarget's Data Center and Virtualization Media Group. Write to her at [email protected] or follow @PariseauTT on Twitter.

Next Steps

Security and DevOps are the perfect match

Chef adds continuous delivery to its menu

Key to Agile and DevOps transformation: continuous integration

Dig Deeper on Configuration Management and DevOps