One of the most common problems encountered by any quality team (whether they are focused on manual testing or automation) is unstable environments. There could be multiple reasons for the cause instability in these testing environments but the bottom line is that it blocks the team from completing their testing. Does this sound familiar to you?
The best way to solve this problem is through understanding the software testing infrastructure and working closely with the DevOps team to build that infrastructure. The amalgamation of testing needs and DevOps gives rise to TestOps. This article outlines my experience with the different components within AWS that can help build a stable and reliable testing infrastructure for a successful CI/CD pipeline.
What is TestOps?
Any kind of operations infrastructure required to set up a testing environment or for running test automation is referred to as TestOps. These days, some companies have dedicated personnel who address test operations challenges.
For the scope of this article, we will walk through the different components on AWS that play a role while setting up a CI/CD pipeline for running a simple application and running tests in a staging/QA environment to validate that the application loads as expected.
Different components of AWS that aid in building a CI/CD pipeline
AWS Code Commit
If your company hires both full-time developers as well as contractors, how do you manage access to repositories for both groups?
CodeCommit competes with Github by providing a fully-managed source control service that hosts git-based repositories. It eliminates the need to create your own repository or worry about scaling your infrastructure when your company’s needs grow. It stores source code and also works seamlessly with your existing Git tools. If your company already hosts its services on AWS, then it is easier to leverage CodeCommit while building your CI pipeline.
It is very secure as it automatically encrypts your files, even during a build. AWS integrates with Identity and Access Management (IAM) to customize user-specific access to repositories. For added security, CodeCommit also uses MFA. These customizations include user profiles that control who has access to which repositories at an organizational level.
The above image shows my repository on my AWS management console. As you can see, the GUI is fairly user-friendly.
This image shows an example of a pull request prior to merging.
Has the CI job for running your tests failed without even running the test? After analysis, you see the job got kicked off, but the build never happened as it was waiting in the queue, which was a prerequisite for your tests to run, hence they failed as well. This is a common problem faced while using any CI system that doesn’t have the auto-scaling capability.
While there are other CI tools like Jenkins, CircleCI, TravisCI, Github Actions, etc the common bottleneck with these tools is their inability to scale their build queues which ends up causing other jobs to wait and eventually timeout.
CodeBuild uses a serverless framework which is a software package for YAML and command-line interface(CLI) development to deploy code to AWS Lambda function. It starts docker containers to build the code and shuts down as soon as it completes the task.
One of the key attributes of CodeBuild that sets it apart from its competitors is its capability to scale its infrastructure and ensure that the customer only pays for the exact time it used to build the application.
CodeBuild is built on top of Azure pipelines and has capabilities to run specific build commands or add a buildspec.yml file with phases defining each step.
CodeBuild also generates build metrics to give you a comprehensive view of the state of affairs at any given point in time. It is integrated with CloudWatch so you can view logs and debug issues seamlessly.
CodePipeline is the capability to automate the build, test, and deploy steps in the CI/CD pipeline. There’s an option to include manual approvals if needed as well. Each of these steps can include actions and conditions associated with them. So, if a step fails, the action is to stop the pipeline and notify the user.
Have you ever tried testing staging data in a QA environment or vice versa by mistake? Sometimes this action throws an error because each environment has a config file that defines which DB it should be pointing to. Some organizations have unique environments whereas in other places both these environments share the same DB.
CodeDeploy is a mechanism by which you can automate the process of deploying applications to AWS EC2 instances or serverless lambdas. There is a deployment configuration that is responsible for tracking the progress. The application specification file (AppSpec file) is a YAML or JSON file used by CodeDeploy to manage deployment. It provides information to CodeDeploy about which files from your application revision should be installed on the instance during the deployment’s Install event.
AppSpec file consists of hooks, which are scripts that will execute at one of five hooks representing different app lifecycle events.
A CodeDeploy app deployment consists of five phases:
- ApplicationStart, and
At each stage, your AppSpec YAML file will specify scripts for the service to run. Using AWS CodePipeline, we can pass parameters to different environments using environment variables or AWS Lambda variables.
If your organization is already using AWS for hosting its services, then ensuring your testing infrastructure is built on AWS would be the most cost-effective solution. AWS has cost estimators which can quickly calculate your monthly expenses for your CI/CD pipeline. I hope this brief crash course piqued your interest and you’re motivated to explore more about leveraging AWS for your unique scenario and pitch to your organization.