days
1
6
hours
0
3
minutes
2
9
seconds
0
2
search
Become a mean DevOps machine

How to make DevOps work for you: Developer’s cheat sheet

Rami Sass
© Shutterstock / supercaps  

Change is never easy. More and more companies, however, are interested in adopting the DevOps model. In this article, Rami Sass, CEO and co-founder of WhiteSource puts together a cheat sheet of tools and practices that can help your team become a lean, mean, DevOps machine.

As the pressure on software organizations to deliver innovative products and ship updates fast continually increases, there is more and more talk in our software development ecosystem of adopting the DevOps model for its increased efficiency and agility. DevOps promises to help teams keep on schedule without compromising quality, even when bypassing slower manual testing and bug fixing that would traditionally come at the end of the process.

Change is never easy for an organization, and incorporating DevOps into the development lifecycle requires a big transition on many levels, challenging teams to adjust themselves to a new organizational structure. New processes need to be adopted, new skills developed, and new tools have to be integrated.

As the industry veterans at The Agile Admin put it, DevOps is “a cross-disciplinary community of practice dedicated to the study of building, evolving, and operating rapidly changing resilient systems at scale” This demands real change throughout the organization, and it’s not surprising that most people are averse to that. However, if we look past the hype of “organizational culture” or “breaking barriers”, DevOps in a development team is really about implementing methodologies and practices that most of us have already started adopting.

We’ve put together a cheat sheet of tools and practices that can help your team become a lean, mean, DevOps machine.

#1 Continuous Integration

Continuous Integration, or CI, has become a fundamental process in the software development environment, a vital gatekeeper that helps software teams keep code errors from being integrated into their projects and manage code quality before they come up at the end of production when the costs of tear and replace ops skyrocket. That’s why choosing the right CI server to best support your team’s processes is so important.

SEE ALSO: “Open source is not any more or less secure than proprietary or commercial code”

Any developer will tell you that there is one CI server that is better than all the rest, and the variety of tools in the market proves that there are a lot of options to choose from:

Should it be open source or proprietary? How configurable is it? Is there documentation available? How well is it supported?

The questions go on and on.

Some seasoned CI Server users will swear by Jenkins, others have deployed VSTS and couldn’t be happier. And then there’s Travis — it’s supposed to be so easy to install! Or Atlassian — it integrates with Jira! So far, no one tool has been able to check all the boxes. The best way to go about choosing the right CI tool for your organization is to map out your organization’s specific needs, depending on the platforms, tools, components, infrastructure, and processes, as well as the policies already in place, and find the CI Server that answers those requirements.

#2 Software composition analysis

For most of us, third-party and open source components are the gift that keeps on giving. Data shows that most of today’s applications consist of a mere 10% – 20% of proprietary code, and 80%-90% open source and third-party components. What we tend to overlook are the risks involved: one out of every 16 open source download requests is for a component with a known vulnerability. DevOps is all about testing automation, but the innovative application security tools like SAST, DAST, and IAST that work for proprietary software, don’t cover open source and third-party components.

SEE ALSO: Top 4 challenges to adopting DevOps and the best ways to resolve them

These require that we adopt a new set of security tools and practices, different from the ones we use for proprietary code. This is where Software Composition Analysis (SCA) tools come in. Vulnerabilities in open source software are difficult if not impossible to track unless you’re using an automated tool. SCA tools can continuously and automatically analyze an application’s source code, modules, frameworks, and libraries to audit open source and third-party software components. SCA enables teams to identify known security vulnerabilities or licensing issues in products and inventory long before they are released into production.

#3 Teamwork makes the dream work

The good news is that in addition to tools and processes, DevOps is about people. When teams find a way to pool their experience and skills, the result is often just as valuable as any magical automated deployment tool out there. In the olden days, development and operations teams stuck to their own, with different sets of priorities and goals. Not anymore. Adopting a DevOps approach requires that teams that aren’t used to working together find a way to cooperate so that they can succeed in creating and maintaining a development lifecycle that delivers innovative, high-quality products quickly and securely.

This means that all players (we’re looking at you developers, operations, and security professionals) need to respect the expertise that their counterparts bring to the table, and learn how to work together to ensure the process and end product are up to everyone’s standards. TJ Randall, VP of customer success, XebiaLabs warns companies that one of the most common barriers to successful DevOps adoption is accepting that “development isn’t just one team but many.” He says that in his experience, when teams don’t work to communicate and cooperate, “operations struggles to unify the activity into a consistent, repeatable process. It’s tough to figure out how to get different silos to agree to look at what the others are doing and to explain to them why it’s worth their time to do so.”

DevOps and the software team

When you think about it, the developers and the DevOps attitude aren’t really all that far from each other. Developers are a limber bunch, eager to innovate, quick to learn new languages and adopt new methods when necessary. While no one likes their day to day to be disrupted, the changes that we recommended here have already helped dev teams deliver swiftly, while eliminating tedious manual tests and last minute all-nighter fixes. One last tip that is important to remember is that change doesn’t happen overnight, it is a process. Don’t be daunted by the big buzzwords.

Look at your team and the practices you are using, and see what’s slowing you down. Don’t go after every newfangled trend, but talk to the experts you trust in your company and in your professional community. Learn what security and operational methods could upgrade your projects, and are easiest to adopt, and work from there. Stick to these lessons and you’ll become a DevOps ninja before you can say automated software delivery pipeline.

ewrwer

Author
devops

Rami Sass

Rami Sass is CEO and co-Founder of WhiteSource. Rami is an experienced entrepreneur and executive with vast experience in defining innovative products, leading technology groups and growing companies from seed level to business maturity. Before founding WhiteSource, Rami founded Testology and beforehand, led development efforts at both CA and at Eurekify (Acquired by CA). Rami holds anMsC and a BA in Computer Science.


Leave a Reply

Be the First to Comment!

avatar
400
  Subscribe  
Notify of