Components of the SDLC
Overview
In the first article of this series, I wrote about the Agile Story Types, which are the tools used by the various members of an organization to complete work. In the article Embracing Agile: an organizational adoption, I wrote about the steps necessary to get requirements from stakeholders to the development team. In that article, I wrote about the process that an organization uses to successfully achieve a completed product. In this article, I’m going to identify the key components of the SDLC. This article is intended to combine tools, process and automation, to achieve an overall strategy that will lead to the successful release of a Product.
DISCLAIMER: I have intentionally avoided the topics of design and quality assurance. I believe that those topics are so significant, that they require their own articles. Secondly, they might vary significantly in each organization. Readers will need to consider what is appropriate by evaluating their own resources and capabilities.
Before creating a release plan for a specific product, it is important to have a DevOps process in place. What exactly is DevOps? DevOps is the repeatable procedures used for delivering new products, features or capabilities, while managing post deployment support that integrates with development. There are a few key points in my definition that need more clarification. First, the procedures for delivering work should be repeatable, which implies that automation tools must be setup and configured properly for the specific product. Second, the setup and/or creation of automation tools are tasks within one of the sprints and they will receive testing in the same manner as any code that is written. Finally, any changes made by the operations team must be incorporated into work being performed by the development team.
Components
The following components are the foundation of a DevOps program. These components should be reviewed, audited and updated regularly to ensure proper compliance and function. These components and their implementation will vary based on the organizational resources and strategy, however here are some of the core components:
Source Control
A system with a proper plan for versioning development is critical when you need to identify the features and capabilities that are included in a particular set of changes. Versioning allows an organization to track the integration between services that are known to be stable, which allows for greater modularity.
Continuous Integration
Regular integration of work products helps to identify problems sooner rather than later. This process will allow integration test cases to be performed and it exists to prevent code that works in the development environment being deployed to production only to find out that it fails when integrated with other services.
Continuous Deployment
This practice allows for work products to get installed into various environments regularly and often enough to complete performance, security, and validation testing. Also, it enables developers to have the latest code base to work with during their Sprint.
Testing Integrations
The types of tests that must be executed will vary by the methodology used for coordinating development and testing. Test driven development is a useful strategy because it incorporates test planning design into the Sprint planning phase, however it's only one of many approaches that can be used in an SDLC.
Testing frameworks
There are numerous testing frameworks available, and they have a tendency to correlate with the development tools that have been chosen. For example, .NET has a test framework and it can be configured to perform specific test cases based on certain actions performed.
Security testing
These test cases should be performed prior to any release to production since they are a critical step in any Cyber-security program. It seems that there are many organizations without a comprehensive security testing strategy, and we have seen many breaches as a result. The latest practice in most cyber security programs is a zero-trust architecture. Regardless of the architecture, these test cases will attempt to simulate a malicious person that is intent on breaking the application, database or network.
Static/Dynamic Analysis testing
A search of static analysis testing will tell you that code isn't executed, instead it is reviewed for compliance with coding standards and the design plan. In the past, these actions were performed by one to several others, however recent innovations have led to the implementation of tools that perform this step. Code reviews were a useful tool in which developers received feedback regarding the coding standards and the team was able to discuss performance issues related to coding techniques that were implemented.
In dynamic testing the code is executed to ensure that it works as expected. These test cases differ from the validation test cases because they are performed on the module where the work was completed. Often times, this type of testing is done in coordination with some type of Software Composition Analysis(SCA) tool. An SCA tool helps analyze the Open source libraries used in an application, and they will evaluate the remote libraries for performance and licensing requirements. An SCA testing process might be a standalone process due to the importance of ensuring compliance of licensing regulations.
Validation testing
These test cases will depend on the environment that code is deployed into. For example, when deploying to a development environment, these test cases ensure that new features or capabilities are reachable even if they don’t perform many functions in the backend yet. When deploying to a Test, UAT or production system, then this process will expect specific results. This type of testing ensures that changes are working as expected, so the various use cases must pass successfully after any deployment.
Summary
These topics are just some of the ones that make up a well designed DevOps strategy, and each organization will customize their program to fit their particular SDLC needs. When combined into a repeatable process, then stakeholders and developers are able to agree to delivery dates for work products. Additionally, a Scaled Agile SDLC allows organizations to perform work on different systems simultaneously, and each product has its own release plan.

