“It is really critical not only to build code, in a continuous fashion, but you also want to build code with quality. Static code analysis, unit testing, code coverage, and post deployment testing are all stages that should be included in your pipeline to ensure your code has quality when building the pipeline and deploying it.” – David Dang, VP of Automation Solutions
DevOps Development Pipeline Inclusion
Static Code Analysis Tools
Static code analysis is an analysis of software that can be performed without actually executing the program and allows you to:
- Analyze code syntax for correctness
- Enforce code styling standards across each code file
- Find instances of duplicate content
- Identify security vulnerabilities (such as SQL injections, outdated features, data loss)
- Identify sections of code that can be refactored to improve performance
Time 00:32 In short, static code analysis tools can improve your application’s performance and overall security, and improve readability of the source code. This stage should take place during the “create” phase of the CICD pipeline (and should be run before software testing begins). When choosing a static code analysis tool(s), you want to make sure to choose one that supports the programming language the project was built with.
To name a few, some of the popular static code analysis tools are:
- Amazon CodeGuru
Time 1:35 The next step of the test pipeline is unit testing, which is done in the “coding” stage. Unit testing covers the smallest possible testable parts of code (a unit) in isolation from other units to ensure it behaves as intended (i.e. could be an entire module, class, or an individual function, or method).
From a cost perspective, unit testing allows for you to save time by testing and locating errors earlier (which in turn decreases cost spent on developers), and allows you to deploy more quickly (ultimately saving cost spent on code going out into production). By testing the smallest bits of code you increase iteration speed and remove the guesswork out of refactoring code and enables easier and more thorough regression testing. A decent unit test also forces dev to think more thoroughly through all of the inputs, outputs, and error conditions which can lead to better code and better code structure (…and that should ultimately lead to code that is easier to maintain and understand).
Time 2:32 The second part of unit testing, unit-integration testing, links one to two layers (up or down) from your current unit. Unit-integration tests eschew mocks, stubs, and fakes in favor of your real programming functionality – your actual code. While unit tests can reduce uncertainty in the individual parts themselves, unit-integration testing is what verifies the sum of the parts together. Keep in mind that unit-integration tests should not replace unit tests, it’s meant to enhance the value you’re getting from unit tests (they compliment one another).
Time 3:02 The next stage of the pipeline, code coverage, is the percentage of your code that is covered by automated unit testing. For example, if you have 100 lines of code and you write tests that only cover 80 lines of that code, the code coverage would be 80%. The benefits of code coverage allow you to see the code that was executed, reveals un-executed application code, provides valuable insight into how the code works (i.e. Are you analyzing the code correctly to make changes to it? How is it interacting?… etc.), and makes developers think more about code.
Two myths/pitfalls of code coverage: A common myth of code coverage is that the higher percentage code coverage means higher quality code, but this is not the case. For example, a developer can write a lot of bad unit tests and still have high coverage. In all, code coverage provides insight but not the quality of those tests. Time 4:47 Another problem with code coverage is that management often uses it to drive success of a project or as a standard measurement of how well development is performing (remember code coverage does not ensure quality).
Post Deployment Testing
Time 5:27 The last step of your pipeline is what we call post deployment testing, which includes service testing and UI smoke testing. The first part of post deployment testing, service testing, which is a conceptional layer above unit testing, while still being significantly faster and less complex than UI testing. Service tests are performed by sending requests to service endpoints and then validating that the corresponding response is as expected.
There are a variety of tools that can be used to perform service testing, such as:
- SOAPSonar… etc.
Time 6:33 The second step to post deployment testing, UI smoke testing, is done before accepting a build for further testing (the goal is to verify that basic user interface functionality is working as expected). These are functional tests that exercise the complete program with various inputs. If they were to fail the pipeline should automatically reject the deployment. UI smoke tests provide more effective QA as a whole by detecting bugs earlier and speeding up troubleshooting; it adds another layer of confidence to application builds. Automated framework that navigates through the screens of an application and verifies that the layout is correct and that they key functions (forms, carts, file upload/download, navigation links) are working correctly.
That's a Wrap!
Time 7:17 As you can see, it’s critical to include these quality stages in your development pipeline to ensure you have a mature, optimal development pipeline. You want to make sure you have:
- Static code analysis – to check for code quality and cyber vulnerability,
- Unit testing – including unit testing and unit-integration testing,
- Code coverage – to give you an idea on how the tests perform or what portion of the code is being covered by those tests, and
- Post deployment testing – to ensure you have service level automated tests and also UI level automated tests.
Most importantly, because it is a development pipeline, you want to keep all the stages that we mentioned in the first video, including the quality gates, to about 30 minutes. This allows for fast feedback to the development and QA team to ensure that the build or deployment are working correctly.
Stay tuned for more upcoming videos on optimizing the stages of your quality pipeline.
>> Subscribe to Zenergy on YouTube for more videos.