CI Tools and Best Practices in the Cloud

Continuous Integration

Subscribe to Continuous Integration: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Continuous Integration: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Continuous Integration Authors: Elizabeth White, Flint Brenton, Gordon Haff, Yeshim Deniz, Stackify Blog

Related Topics: Continuous Integration, DevOps Journal

Blog Feed Post

Continuous Delivery Requires New Approaches to Security By @madgreek65 | @DevOpsSummit #DevOps

The rate at which production changes occur requires us to take a fresh new look at securing systems

Continuous Delivery Requires New Approaches to Security

As companies embrace the DevOps movement, they rely heavily on automation to improve the time to market for new features and services. DevOps is a long, never-ending journey with a goal of continuously improving the software delivery process, resulting in better products and services and, ultimately, happier customers. At the beginning of their DevOps journeys, many companies focus on continuous integration (CI), in which they automate the build process. Automated testing is implemented so that builds will fail if any changes fail the baseline tests. The idea here is to never move bugs forward, catching them early in the process.

Once companies get good at implementing CI, continuous delivery (CD) is the logical next step. The idea with CD is to be able to deliver a clean, consistent environment along with the automated build. One of the biggest bottlenecks I see with clients is inconsistent environments. How often do we hear “it worked on my laptop” when a build fails in a testing environment? Too much time is wasted fixing environment issues, leading to lost productivity and a decrease in overall quality. CD aims at fixing all of this by ensuring that no matter what environment a build is deployed to, the configuration of that environment is always the same.

Companies that have implemented CD are usually in a position to deliver to production frequently, possibly even multiple times a day if necessary. This presents a challenge to the legacy methods of inspecting for security vulnerabilities. In the past, manual security reviews were a common method of inspecting software to protect against introducing new vulnerabilities into the production environment. Now that companies can deploy daily, manual inspection is no longer feasible. First, manual inspection doesn’t scale. By that, I mean that if a company has ten teams that can all deploy software each day, there is likely not a big enough security team in house that can respond to the constant need for security inspection. Even if there were enough security personnel to perform these inspections, it would be a full-time task for these people, and other tasks would fall to the wayside. Second, manual inspection would get in the way of the development teams and reduce the number of times they could deploy in a day, due to the constant need to stop the automation process to hold a meeting to manually inspect software.

Read about new ways to approach security in my latest post on the Virtualization Practice.

Read the original blog entry...

More Stories By Mike Kavis

Mike Kavis is Vice President & Principal Cloud Architect at Cloud Technology Partners. He has served in numerous technical roles such as CTO, Chief Architect, and VP positions with over 25 years of experience in software development and architecture. A pioneer in cloud computing, Mike led a team that built the world’s first high speed transaction network in Amazon’s public cloud and won the 2010 AWS Global Startup Challenge.

An expert in cloud security, he is the author of “Architecting the Cloud: Design Decisions for Cloud Computing Service Models (IaaS, PaaS, SaaS)” from Wiley Publishing.