The previous chapter in this WhiteHat Security series discussed Codebase as the first step of the Twelve-Factor App and defined a security best practice approach for ensuring a secure source control system. Considering the importance of applying security in a modern DevOps world, this next chapter examines the security component of step two of the Twelve-Factor methodology. Here follows some actionable advice from the WhiteHat Security Addendum Checklist, which developers and ops engineers can follow during the SaaS build and operations stages ...
Here in the software world, we have entered a fine place of development, a future in the present all the while the days of yore where nothing more than deployed hardware and manual database-type solutions that were once used to manage huge amounts of otherwise unmanageable and disparate data. No more are we necessarily bound to displaced tools used to, at one time or another, manipulate the multiple service needs across most business organizations.
We are beyond the beginning of technology advancements and we continue to accelerate faster than organizations are able to adapt toward further innovation. In the service management sector there are many more changes to come, a great deal of evolution ahead. A simple truth, though: Organizations must find a way to future proof themselves or face some tough realities. As data moves quicker and adeptly through our organizations, we must ready ourselves for this speeded up flow of information. Continuous improvement on architectural and at the organizational level by leveraging DevOps for the service desk may in fact help bring this data under control.
A move to a continuously delivered environment is a move to an agile environment with a solution-focused approach is an adept move; Facebook and Netflix use such strategies, which continue to develop fresh ways to enhance user experiences. Through DevOps and continuous delivery, organizations are able to become leaner, efficient and forward thinking.
By focusing more on requirements or what we should be delivering instead of focusing on how to implement it, we do away with the old code-driven approach to technology management and services provided. Once code is implemented not only is it short lived, but once it's written you are also stuck with it. You build your organization on the architecture, but when implementing continuously delivered language, we are ready for rapid changes: Anything new that comes out can immediately be pushed out through your organization, deployed and used every day.
Taking such an approach allows scalability. This approach brings us back to the feeling of the industrial revolution; it is such an exciting time with new things lining up one after another.
On the topic of development and, more specifically, the speed of delivering these new developments, there's the topic of the "old waterfall" approach where there are always bottlenecks along the way; for instance, products that had been developed a year prior simply sit on the shelf waiting to be used. When these products are finally ready to be tested, any issues that may be identified keep the product tabled and get pushed to a later release even further down the calendar.
Thus, with changes in architecture, continuous delivery can become a goal with DevOps enabling the process of getting there. Continuous delivery means that since new builds or versions of software are constantly available, you must be able to trust the code and what has been created at any given time. Where in a waterfall approach, changes of long periods are combined and then tested, a continuous delivery method means there is now a change in priorities to defining critical workflows that have to be covered by automated tests, creating more security of the quality of the version.
Also, a continuous delivery approach changes the impact and responsibility of a developer as they are constantly required to think about testing. When there is a new build of the product every day and something created does not work, there can be no further builds until any issues are resolved. To improve the quality controls, critical workflows have been defined, and the notion of "blockers" has been introduced in the development prioritization process. All in all, the planning remains much more flexible now, as does the business' operation.
With continuous delivery, made possible by DevOps, there is a clear increase in the quality, as well as more automation and better collaboration on the product, with a focus on user friendliness and ease of use for those who work with the solution. Feedback and communication from support is much quicker as the pace of development and delivery increases for the service desk, too.
A nice example of how this works with continuous delivery powered by DevOps is through the use of cloud-based service management solutions, especially when new functionality is enabled by the Shift Left strategy for the service management department, but also for end users. With this approach, you can implement such functionalities, taking into account direct feedback from your customers and all of your departments to provide the best service available.
Thus, trends and requirements that come up can immediately be communicated, developed, delivered and deployed without sitting around on a shelf for several months while you wait for the next delivery date. Now the process truly is agile.