DevSecOps

• What is Software Development Lifecycle (SDLC)?

  • The Software Development Lifecycle is a set of practices that make up a framework to standardise building software applications. SDLC defines the tasks to perform at each software development stage. This methodology aims to improve the quality of the software and the development process to exceed customer expectations and meet deadlines and cost estimates. For example, with customer demand, computing power increases, which raises software costs and developer dependence.
• How does SDLC work?

  • The Software Development Life Cycle provides the guidance required to create a software application. It does this by splitting these tasks into phases that form the Software Development Lifecycle. Standardising the tasks within each phase increases the efficiency of the development process. Each phase divides into granular tasks that can be measured and tracked. This introduces the capability of monitoring to ensure projects stay on track. The aim of SDLC is to establish repeatable processes and predictable outcomes from which future projects can benefit.
• SDLC PHASES:

  1. Planning: The planning phase encompasses all aspects of project and product management. This includes resource allocation, project scheduling, cost estimation etc.
  2. Requirements Definition: is considered part of planning to determine what the application is supposed to do and its requirements. For example, a social media application would require the ability to connect with a friend.
  3. Design & Prototyping: establishing how the software application will work, programming language, methods to communicate with each other, architecture etc
• SDLC PHASES:

  • 5. Software Development: entails building the program, writing code and documentation.
  • 6. Testing: In this phase, we ensure components work and can interact with each other. For example, each function works correctly, different parts of the application work seamlessly together, and performance-wise, there are no lags in processing etc. 
• SDLC PHASES:

  • 7. Deployment: in this stage, the application or project is made available to users.
  • 8. Operations & Maintenance: this is where engineers respond to issues in the application or bugs and flaws reported by users and sometimes plan additional features in future releases.
• Planning

  • As part of the Planning Phase, also known as the Feasibility Stage, the scope and purpose of the application are determined. Software development is planned and implemented using it. Additionally, it helps to keep the project focused on its original purpose while setting boundaries.
  • Here, the system's problem and scope are defined, and the requirements for its upcoming design can be determined. The process of devising an effective outline for the forthcoming development cycle should enable issues to be caught before they have a detrimental effect on the process.
• Requirements Definition

  A system's requirements stage involves defining the prototype ideas and gathering all the necessary details. This may be in the form of:

  • Making a list of all the requirements for the prototype system
  • Prototypes should be evaluated for alternatives
  • Identify the end user's needs through research and analysis
• Requirements Definition:

  • Planning for the application involves defining the requirements to determine what it should do, and its needs. An application that uses social media
  • Defining the resources needed to build the project according to the requirements is also critical. For example, software might be developed to control a custom manufacturing machine. A device is required for the process. It is common for developers to produce a document known as a software requirement specification (SRS).
• Design and Prototyping

  It is first necessary for developers to outline the details of the overall application, including its attributes, such as:

  • Interfaces for users
  • Interfaces between systems
  • Requirements for networks
  • Instances of databases
• Design and Prototyping:

  • SRS documents are usually converted into logical structures implemented in programming languages. Plans for operating, training, and maintaining the system will be drawn up to ensure developers know what they need to do throughout the life cycle.
  • Here are a few examples: An architecture specifies how codes are written, industry practices, the overall design and any templates or boilerplates used within the program. 
• Design and Prototyping:

  • A document called an Architecture Design Review (ARD) is typically created by engineers and developers at this stage to ensure that all teams working in different areas are on the same page. In the case of an API endpoint, for example, front-end and back-end developers and teams handling authentication and authorisation will be involved in the ARD process.
• Software Development

  • Code is written, and an application is developed based on specifications outlined in earlier design documents. Software developers appreciate instructions and explanations.
  • Playbooks and guides for the application can be documented as part of the documentation process. Developers will use compilers, debuggers, and interpreters to adhere to coding guidelines established by the organisation. A very effective initiative to promote secure coding would be incorporating code hygiene, code best practices and security in playbooks.
• Testing

  • It's critical to test an application before making it available to users. During the testing stage, developers will review their software using automated tooling, like source code scanners. The project's goal is to meet the previously defined quality standards during the planning and requirement stages.
  • For example, a Quality Team with Quality Analysis (QA) Engineers. The most notable phases when introducing testing are test case design and development, test environment set up and test execution.
• Test case design and development

  • With the test plan in place, testers can begin writing and creating detailed test cases. In this phase, the QA team fleshes out the details of the structured tests they will run, ensuring that it meets the requirements set in the previous SDLC phases. When conceptualising test cases, the tester's goal should be to validate functionality within the allotted time and scope, especially core functionality. 
• Test cases should be simple, well understood by any team member, and unique from other test cases. Test cases must be identifiable and repeatable, as developers will add new functionality to the product over time, requiring tests to run again. They can't change the test environment for future tests, especially when validating configurations. Test cases might also require maintenance or updates over time to validate both new and existing functionality. Once test cases are ready, a test team lead or peer can review them or check and update automated test scripts. 
• Test environment setup

  • The test environment provides the setting where the actual testing occurs. Testers must access bug reporting capabilities and the application architecture to support the product. Once ready, testers establish the test environment's parameters, including the hardware, software, test data, frameworks, configurations and network.
  • For example, most of a product's users might be on an Android device, use a specific version of a Chrome browser and have a certain amount of processing power on those devices. These are parameters the test environment would include. 
• • Test execution: At this stage, testers execute all test cases. For example, QA engineers and automated scripts run several functional and non-functional tests. Testers will identify and report detailed bugs from test case execution and log the system's performance compared to its requirements. Often testers retest the product, as part of regression testing, as developers make fixes to ensure new flaws don't get into production. With all of these tests piling up in the test execution phase, it's essential to use test automation to achieve the test coverage and velocity you need.
• Deployment

  • After testing, the overall design for the software starts to come together, and different modules or configurations are integrated into the primary source code. After this stage, the software is theoretically ready for market and provided to end-users. Many companies automate the deployment phase using tools 
  • These tools focus on what you call "Software Deployment tools" for release management; the focus is on automating software rollouts so that teams can deploy new applications on all machines or just selected ones.
• Deployment:

  • Popular Software Deployment tools are Netlify and Argo CD. During the deployment phase, a new feature on the company's website can be released, or in the case of mobile development, download a new application version on a smartphone.
  • Furthermore, automating the deployment processes also allows the capability to rollback a deployment, making it easier to go back if there are any unforseen circumstances with the deployment.
• Operations and Maintenance

  • Practising any activities required to handle issues reported by end-users. Furthermore, developers are responsible for implementing changes the software might need after deployment. In this phase, users discover bugs they didn't find during testing.
  • For example, handling residual bugs that could not be patched before launch or resolving new issues raised during user reports. Developers now focus more on stability and uptime than developer velocity, and operations teams now have a stake in developer velocity and their traditional role of maintaining uptime. 
• Operations and Maintenance: DevOps:

  • They enable self-service for developers to promote developer velocity, where developers seek their solutions. Operations teams work closely with developers to provide on-demand access to secure, compliant tooling and environments.
  • They standardise tooling and processes across the business. The best way to enable a sustainable self-service model and empower teams to work autonomously is by standardising tooling. 
• Operations and Maintenance: DevOps

  • Tools and techniques that are standardised and well documented enable organisational unity and greater collaboration. This reduces the friction developers and operations teams experience when sharing responsibilities.
  • DevOps teams focus on empowering other teams through self-service and collaboration. Standard operations tasks like resolving incidents, updating systems, or scaling infrastructure still need to be addressed. When development and DevOps work closely together, teams automate the repeatable tasks and drive consistency across the organisation.
• DevOps:

  • DevOps teams can track and monitor metrics thanks to consistency and automation of tasks. For example, by automating the creation of virtual machines in the cloud through Terraform, you can log activity for virtual machines created and accessed. 
  • You can extend this further by creating alerts for how the service accounts/roles are used to develop infrastructure from a security and compliance point of view.
  • As example of this would be Vagrant or Ansible. The code controlling operations systems must be stored, versioned, secured, and maintained. 
• CALMS: Culture:

  • DevOps isn't simply a process or a different approach to development; it's a culture change. For any DevOps adoption to be successful, an organisation will have to make a culture shift. Rather than the slower, full-release approach of the waterfall model, teams will have to adopt new strategies to break projects into smaller tasks that can be completed and then presented in a series of sprints.
  • This culture shift is required for all employees, including not only the development teams but also QA, product management, and operations.
• CALMS: Automation:

  • A large part of DevOps is the focus on automation. Since we are breaking projects into smaller components, it would be inefficient to then manually integrate these components into the final solution.
  • Thus, it is better to spend some time creating automated processes that can ensure that new feature integrations can occur in a reliable and repeatable manner. This is usually started on the continuous delivery side of things for new teams. But as teams mature, it will also move to continuous integration.
• CALMS: Lean

  • By implementing DevOps, we want to make sure that tasks are broken as small as possible. This allows teams to create initial versions of applications sooner. The common principle is that we are constantly improving our software, but it is more valuable to get a version of our application in the hands of users earlier rather than having to wait years until the product is fully perfected.
  • Thus, we start with a lean first version that is constantly improved with time. This method also allows our user base to provide feedback and a wishlist of features for the application.
• CALMS: Measurement

  • When implementing DevOps, it is important to have some sort of measure of effectiveness. These metrics are important since they will help us make small changes to our processes and ensure that we are constantly improving.
• CALMS: Sharing:

  • In an effective DevOps pipeline, there is a shared responsibility for the overall application between all teams, including development and operations. Understanding that all team members are required to deliver the final solution and share in the responsibility to do so will result in a better product for users.
• DevOps Metrics:

  • Meantime to production (MTTP). What is the turnaround time for newly committed source code?
  • Frequency of deployment. What is the frequency of deployment of releases? The average lead time. How long does it take to develop, build, test, and deploy a new feature?
  • Speed of deployment. A new release is deployed into production; how long does it take?
• DevOps Metrics:

  • Deployment Agility. You can measure deployment agility by combining deployment speed and frequency.
  • Production failure rate. How often do failures occur in production?
  • MTTR stands for mean time to recover. What is the recovery time after a failure?
• MTTP

  • One critical DevOps metric to track is the mean time production. MTTP is the length of time between when a code change is committed and when it is in a deployed state.
  • A pre-release test, for instance, is passed when all code requirements have been met. Test automation and working in small batches are good ways to improve MTTP time. Developers can receive fast feedback on the code they commit by following these practices, identifying flaws, and fixing them as quickly as possible.   
• Failure Rate

  • When a code change goes into production, a certain percentage of code changes require hot fixes or other remediation measures. It does not measure failures caught during testing and fixes before the code is deployed.
  • The same practices that enable shorter MTTP times correlate with reducing change failure rates. All these practices make bugs much easier to identify and remediate. Tracking and reporting failure rates are essential for ensuring new code releases meet security requirements.
• Deployment frequency

  • Understanding how often new code is deployed into production is critical to DevOps' success. Deployment frequency defers to MTTP as it measures when it's released into a pre-production staging environment and reserves "deployment" to refer to code changes released into production.
  • Teams can deploy changes on-demand and often many times a day. The ability to deploy on-demand requires a deployment pipeline that incorporates automated testing and feedback mechanisms
• MTTR

  • When a partial or total service interruption occurs, the mean time to recovery (MTTR) is measured. Keeping track of this metric is crucial. If a failure occurs, a fix must be deployed as soon as possible, or the changes that caused the failure must be rolled back.
  • In most cases, this involves monitoring system health continuously and alerting operations in the event of a failure. The operations team have the necessary processes, tools, and permissions to resolve incidents. 
• Communicating Risk

  • You can demonstrate improvement over time by measuring any of these, and you'll have the evidence to support the buy-in from the business and teams. Risk means very different across teams. For DevSecOps engineers, risk means the likelihood of a vulnerability being exploited and its impact on systems.
  • Whereas for a DevOps engineer, a significant risk would be high rates of production failure, for example. By understanding other teams' definitions of risk, a DevSecOps engineer can find common ground and better build a perception of security risk for other teams.