Agile methodologies have allowed software development to be optimized, but do not consider the additional processes required to deliver new versions to users. Development is fast, but delivery is still slow. The DevSecOps culture takes these methodologies to a new level so that you can optimize delivery of new releases to ensure innovation without compromising on expected compliance, performance and security.
DevSecOps is a comprehensive set of cultural practices and values that have been proven to help organizations of all sizes improve their software release cycles, quality, security and the ability to gain rapid product development feedback.
Why adopt DevSecOps?
The main problem faced by software developers is how to turn a good idea into a system and deliver it to users as soon as possible.
The company Puppet famous for its widely used configuration management system, conducted a survey in 2016 of more than 25,000 IT professionals around the world on the use of DevOps over 5 years and provided a report that highlights:
- Organizations that practice DevOps effectively achieve a deployment rate of up to 200 times more often and spend less than half the time on this process.
- They often have 3x fewer failures and when they do, they can recover in up to 24x less time than low-performing companies that don’t embrace DevOps.
- These companies also spend an average of 22% less time on unplanned jobs or rework, and as a result, they can spend 29% more time on new jobs, such as new features or code.
- And about security, they usually spend 50% less time on vulnerability fixes.
DevOps adoption in the world
Download the reports to check other metrics and all the details:
Benefits of adopting DevSecOps
- Reduced cycle time to deliver value faster and increase the profit.
- Reduced efforts to increase efficiency and reduce costs with support.
- Increase predictability over the software delivery lifecycle to make planning more effective.
- Ability to adopt and maintain an attitude of compliance with any regulatory regime to which the company may be subjected.
- Determine and manage the risks associated with the delivery of software effectively.
- Reduced costs through better risk management and fewer software delivery issues.
DevSecOps General Concepts
DevSecOps aims to establish a culture and environment where the construction, testing, and release of software and services can happen quickly, frequently, and with minimal support, to continually increase business advantage and customer satisfaction. DevSecOps takes the Continuous Integration, Continuous Deployment, and Continuous Delivery practices.
DevSecOps is based on the Lean concept, a practice that essentially consists of directing resources and production efforts to just what adds value to the end customer, eliminating additional tasks that are considered wasteful.
In the DevSecOps context and based on this Lean concept, software that is not delivered often is like stock held in a warehouse. It cost money to manufacture it, but it does not produce any financial returns, it actually costs money to store it as well.
Undeliverable software is a waste.
Lean, via Wikipedia
Efforts must therefore be focused on reducing waste to create a value-based delivery flow for the customer.
Time-to-marketing reduction
Applying this concept leads to a Just-in-Time business: a production system that creates and delivers only what is needed, when needed and in the quantity required.
In order to apply this concept, DevSecOps also relies on agile development methodologies that make it possible to create small, recurring versions of software to continually validate and adjust planned delivery scopes to reflect what users perceive as valuable, eliminating waste and creating a production chain oriented to a value stream for its users.
Small deliveries and engagement system
But delivering small and recurring new versions of software at a steady pace involves a number of challenges. Each new version to be released is a potentially critical event that, if it fails, could compromise the customer experience and consequently lower the value of the business. It is important to add new values such as innovations and speed, but above all we must ensure that the values can be experienced properly. These two poles are common challenges in any business and are known as System of Engagement (SoE) and System of Register (SoR) systems.
SoE is the term used to represent the business actions needed to stay agile and innovative. Similarly, SoR represents another part that needs to keep everything working. The problem is how to make SoR quickly adapt to expected changes in SoE to maintain business continuity. This challenge is known as bimodal IT. Development Teams is a sector that represents the SoE motivations of a company, while the Operations team, the SoR. The practice of DevSecOps leads to the consolidation of these two systems so that you can be agile without compromising business continuity.
CI – Continuous Integration
The first common action taken to achieve DevSecOps is to deploy a Continuous Integration process or commonly known as Continuous Integration (CI). This is the most valuable technique for companies that want to optimize their development processes. Continuous Integration automatically conducts the build and apply functional testing processes with each commit made, providing feedback, metrics and reports instantly to the entire development team. It is very common in traditional and less optimized projects for the application under development to be in a nonfunctional state for a long time. Especially in large projects with many branches, the new version under development will be unusable for most of its development. Even when there are unit tests run by developers on their machines, it often takes a long time for them to find out if the application will continue to function when the new functionality is merged because it relies solely on testing only in the later stages of Acceptance.
code, which makes it difficult to correct. Worse still, one may later discover that the new version does not serve the purpose for which it was intended.
There is another problem that can occur in these streams: As the development team takes time to receive answers on completing the validations required for the new version to go into production, when I need to fix any bugs, they will already be allocated and other tasks and there will be competition between fix inappropriate code taken for granted and new features under development, choking these teams and delaying planned delivery times.
By contrast, in projects that adopt Continuous Integration, the software under development is in a nonfunctional state for only a few minutes when the changes, which are small and incremental, are being applied. Continuous Integration requires the application to be compiled with each new change and a comprehensive set of automated functional tests to be performed automatically to ensure within minutes that the work done by developers has actually reached a ready state.
With Continuous Integration, whenever a build fails, the development team receives automatic feedback and stops any work in progress to correct the new change. Non-functional software has no value to users and is a waste.
The goal of Continuous Integration is to keep the software in a functional state at all times.
Continuous integration represents a paradigm shift. Without it, the software will be considered non-functional until it is proven to work, which usually happens during the acceptance or integration testing stage. With continuous integration, software is assumed to be working (as long as there is a considerable set of automated tests) with each change – you know when the application crashes and can fix it immediately.
Teams that effectively adopt Continuous Integration are able to deliver software much faster and with fewer defects than teams that do not use it. Defects are discovered earlier in the delivery process, and it is cheaper to fix them, which represents cost and time savings. Therefore, we consider the practice essential for professional teams.
Continuous Delivery and Deployment
Continuous Integration brings a proven productivity breakthrough to any business, regardless of size. But its not enough. It focuses mainly on development teams and for software to go into production, additional validation is required to certify non-functional aspects such as capacity, performance, availability, security and usability. You need to test new releases in preproduction environments that are the same as or very close to production to consider the architecture that will support the application.
If these validations have not been done at a steady pace, without major interruptions, and within the timeframe of Continuous Integration, there will be bottlenecks in the delivery flow and developers will continue to wait a long time to receive feedback on their releases and when needed. dealing with detected issues will probably already be allocated to other tasks, making corrections difficult and impacting software evolution.
This will make it difficult to build the value stream-oriented production chain and reduce waste with retained and undelivered codes to users. Remember, undeliverable software is stock and therefore a waste.
For the benefits of Continuous Integration to be fully realized the solution is to adapt Continuous Integration to a more holistic, end-to-end view of the entire delivery process. Quickly created releases need to go into production as soon as possible. And for that, all these complementary validations need to be performed in a timely manner, which involves adopting automations to reduce risk, ensure compliance and security. In DevSecOps this leads to the adoption of an predictable, repeatable and reliable automated delivery pipeline that is called Continuous Delivery or Continuous Deployment, depending on the release strategy.
In Continuous Delivery, after CI validations, the release is automatically provisioned in preproduction environments with the same configurations used in production where acceptance testing will be performed. However, provisioning in production is not automatic and is a decision to be made according to the desired release strategy.
The adoption of this flow leads to the pull system provided for in the Lean concept. Which, as said, guides production to what adds value to the customer and eliminates work outside this context.
See Anatomy of a CI/CD Pipeline (Continuous Delivery or Continuous Delivery)
Continuous Delivery or Continuous Deployment (CI/CD)
Continuous Deployment, or Continuous Deployment, is identical to Continuous Deployment, but differs from the fact that new releases after they are validated are automatically provisioned in a production environment. This practice is the most optimized in DevSecOps and enables a steady, uninterrupted delivery rate and full practice of the Lean concept. But joining requires high maturity in DevSecOps and adoption of complementary deployment strategies like Green/Blue and Canary. Thus it is more common for companies to adopt Continuous Integration initially, move on to Continuous Delivery, and as they mature, evolve to Continuous Deployment
Since you cannot practice Continuous Delivery without Continuous Integration, this flow is known as the CI/CD pipeline by the market and is the practical manifestation of the DevSecOps culture.
Integration, Delivery, and Continuous Deployment Comparison.
Although the CI/CD pipeline provides automated testing at various levels, it is common to adopt exploratory and complementary manual acceptance testing.
Article originally written by Rodrigo Dias and edited by the Yaman Marketing Team