Insights

DevSecOps removes the barriers which prevent business from delivering and updating systems at speed! DevSecOps keeps companies at the leading edge of technology, supporting a faster, safer, and much more cost-effective delivery of applications.

As part of DevSecOps, there are 10 steps that should ideally be followed by development teams – also as part of their SDLC (Software Development Lifecycle) – to ensure the fastest, safest and most cost-effective delivery of their applications. The step that covers how to quickly and automatically build code, test code, publish code and get it deployed into an environment is the Continuous Integration/Continuous Delivery step. 

Continuous Integration/Continuous Delivery (aka CI/CD) pipelines are a crucial component in all development team’s DevSecOps workflows. The ability to get code committed to source control, get it deployed to test, approved and ready for production is critical to get right and get quick. Not enough checks in a CI/CD pipeline can lead to the code not compiling or working properly, large amounts of technical debt being introduced to code, and may be detrimental to deploy to production. On the flip side, too many checks in a CI/CD pipeline can mean there is a longer time between releases to production. 

Whilst there is a whole multitude of different parts that can form a fully functioning CI/CD pipeline, there are 10 fundamental steps I would always include as part of a CI/CD pipeline to ensure the code compiles, reduces technical debt, ticks boxes around different flavours of testing and enables quick, easy and regular deployments.

10 Fundamental Steps of a Successful CI/CD Pipeline

1. Install packages (and certain  versions of packages) needed to build code

If there are any dependencies or third-party libraries required to run the code, install those dependencies. Without them, the code won’t be able to run properly.

2. Build code solutions to make sure they compile okay without exceptions and errors

Once the dependencies are available, it’s time to compile the code. If the code builds, it will work when deployed to an environment (not necessarily the way it’s expected to work; this is where the various test steps come into their own). If the code doesn’t build, it will present big problems! 

3. Run code unit tests to check that the code units work as expected

Providing the code compiles, it’s time to check if the individual units of code work as expected by running unit tests. If the unit tests pass, happy days! If not, the code probably isn’t working the way it’s supposed to be… which may mean back to the drawing board for the developers! 

4. Run code coverage & analysis to check for clean code

Then unit tests pass… great! But how much code is actually being covered by unit tests? And how clean is the code, or is unnecessary levels of Technical Debt being added to the code solution? Running the code through a scanner, such as SonarQube, allows development teams to pinpoint code smells, as well as seeing how much code is being covered by unit tests. There are also tools available to scan for security vulnerabilities; SonarQube does this, as well as Sonartype Nexus IQ, adding that “Sec” element to the DevSecOps CI/CD pipeline. 

5. Run performance tests on committed solutions

It wouldn’t be a Capacitas insight without a nod to performance, and with good reason too! Performance tests can range in their implementation; from basic stopwatch tests of code, to test speed, to fully integrated Test Automation Frameworks that trigger performance tests and automatically log performance data into data analytics dashboards like Dynatrace. Not having any form of performance tests in your pipeline really is not an option. 

6. Run security tests on committed code solutions

Whilst code scanning may pick up prospective security vulnerabilities, nothing beats a simulated Penetration Test on the system being developed! Rather than having to wait a year for the next compulsory PEN test, scripts can be created and baked into the pipeline to simulate certain parts of the PEN test. For example, you could run tests on API endpoints for different user roles, to check secure access control. You could automate the process of trying to invoke a Cross-Site Scripting or Injection Attack on elements of the system. 

7. Configure/tweak file contents before publishing to the deployable package

If there are multiple pipelines to publish code for multiple different environments, there may be a step needed to change hard-coded values in code (for example, version numbers or dev-test-prod specific CSS class name) for the specific environment that the pipeline is building for. 

8. Publish code files into a deployable package

Deploying raw code to an environment is usually not ideal. Instead, it’s better to deploy published DLLs or condensed versions of code, to keep source code secure and away from unnecessary exposure. 

9. Make necessary database changes before deploying code to environments

If the code you work with is reliant on connections/interactions with a database, the CI/CD pipeline needs to make sure that there is a step that auto runs any database changes to keep the database up-to-date and functional. 

10. Deploy code into Test or Production environments

The fun part! Now the rest of the steps have been executed and successful, the last step is to automatically take the published code and move into the necessary locations in the necessary environments.