I recently gave a Bright Talk session on adding security to the Agile Cloud/DevOps Development cycle. Part of this discussion addressed adding security testing as part of the process before, during, and even after continuous deployment. In other words, if we continually deploy, we must continually test. Our testing needs to be in the multi-minded parallel process we use for modern development, not the single-minded pipeline acceptable to most DevOps or agile processes. In the past, a team of people would test, each working independently to improve our software. We need similar capabilities within our automated processes. How do we achieve this? How do we add automated, continual testing? And where can we add this to our process or pipeline?
Articles Tagged with continuous deployment
A lot of new technologies and techniques were invented and developed to enable large cloud businesses. Enterprise IT organizations are now looking at these innovations with an eye toward realizing business benefits from doing the same thing. Techniques like continuous integration (CI) and continuous delivery (CD) are helping cloud companies. Enterprises are looking for the same agility. Both Google and Netflix have been using containers for years, and many enterprises are adopting them now. Most of these businesses are nowhere near the size of Google, or even Netflix, yet they want to use the same techniques. The challenge is that businesses of different scales have different needs. What works at an enormous scale isn’t always right for companies that are merely huge or simply large.
Yesterday I had a chat with the folks at Codeship, a continuous integration and continuous deployment platform. The topic of immutable infrastructure came up and was intriguing to me, so I thought I would write about it. So what is immutable infrastructure? The concept of immutable infrastructure is to never change your existing production servers. Instead, build new automated servers and destroy the old. This concept falls in line with the “fail forward” belief system of many modern-day DevOps evangelists who believe that tweaking servers or rolling back code from servers in highly distributed systems is too risky and causes more problems than it is worth.
I spent two days at PuppetConf 2013 in San Francisco this week, and the common themes were automate everything, monitor everything, provide feedback early in the process, and focus on culture. All four of those topics aligned with the DevOps movement, with the goal of faster and more reliable deliveries. Companies that can deliver software more frequently with fewer issues have a competitive advantage over those who can’t.
The old way of delivering software was to bundle up the software and ship it, sell the software off the shelf, or allow customers to download and install it. In the “shipping model”, it was the buyer’s responsibility to install the software, manage the uptime, patch, monitor, and manage capacity. Sometimes the buyer would perform all of those tasks themselves, or sometimes they would hire a third party to handle it for them. In either case, the buyer of the software had total control over if and when the software was updated and at what time a planned outage would occur in order to perform the patches or upgrades.
I was fortunate enough to catch the live stream of DevOpsDays, held at the tail end of the Structure 2013 conference in San Francisco a couple of weeks ago. There were many really good presentations, and I picked up on a common theme. It appears, and I have seen it first hand, that there is still a lot of confusion about what DevOps really is. Some companies think it is an IT role, like some kind of super systems administrator who can also magically code like a stud programmer. These companies create a new silo called “DevOps” and defeat the whole purpose of what DevOps is intended to do. One by one, presenters at DevOpsDays stomped their feet and said “DevOps is not a role, it is a culture shift!”