Essential Guide

Use these DevOps examples to reimagine an IT organization

A comprehensive collection of articles, videos and more, hand-picked by our editors
News Stay informed about the latest enterprise technology news and product updates.

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 bpariseau@techtarget.com 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

PRO+

Content

Find more PRO+ content and other member only offers, here.

Essential Guide

Use these DevOps examples to reimagine an IT organization

Join the conversation

7 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

How do you reconcile corporate compliance rules with DevOps goals?
Cancel
You have to have an ongoing, honest, and open dialog between the people responsible for establishing the corporate compliance rules and the DevOps teams. The two teams, working together, can ensure that compliance rules realistically address regulatory concerns while accommodating the faster development and deployment cycles the business requires from the DevOps teams.
Cancel
Regulatory compliance has always led to put in place a process and tooling this process to simplify the auditing is a practice now well established. As in all situation when you want to adopt DEVOPS but probably more accurately in this case the processes MUST be adapted. A main reason for failing a DEVOPS initiative is to try to keep the existing process and accelerate them (by automation) ; DEVOPS is a cultural change that should always lead to a change of processes. In the case of Compliance Process it is certainly necessary to validate that they still aligned with the objectives (which you validate with your audit team) but they have to be changed !
Cancel
Corporate compliance rules were made by people and for some reason. I'd look into that. Do we still meet the purpose, and do we need it? Maybe adapt the existing rules. Maybe retire some or introduce new.
Cancel
Regulatory compliance really just boils down to common sense and, as Gruver points out, most auditors ar really just concerned that processes and procedures are consistently followed and documented. That means that, if your processes and procedures are aging and based on the way software was developed and deployed pre-DevOps, you need to revisit those policies, with your auditing team, and update them so that they are applicable in the current world.
Cancel
Regulatory compliance has always led to put in place a process and tooling this process to simplify the auditing is a practice now well established. As in all situation when you want to adopt DEVOPS but probably more accurately in this case the processes MUST be adapted. A main reason for failing a DEVOPS initiative is to try to keep the existing process and accelerate them (by automation) ; DEVOPS is a cultural change that should always lead to a change of processes. In the case of Compliance Process it is certainly necessary to validate that they still aligned with the objectives (which you validate with your audit team) but they have to be changed !
Cancel
Then DevOps shouldn't be an "ointment" (or silver bullet). That really depends on how and what for DevOps is being sold.
"One click promotion" to production is not necessarily a good thing - and roll back is not always the answer. Software has more and more impact on us; injuries and death can't be just "rolled back".
Cancel

-ADS BY GOOGLE

SearchDataCenter

SearchAWS

SearchServerVirtualization

SearchCloudApplications

SearchCloudComputing

Close