Driving DevOps Engagement with Great Architecture Diagrams and QA Procedures

Many organizations want to leverage cloud environments like Amazon Web Services (AWS) to deliver high-quality products to their customers. But the number and complexity of cloud services can take focus away from building products. Working with a cloud partner, like Mission, is an excellent way to get up to speed with AWS’s capabilities and give your organization access to AWS expertise.

DevOps’ intent has always been to bridge the gap between development and operations teams through taking ownership of solutions from start to finish. And while we at Mission are here to meet you wherever you are in your cloud adoption journey, there are extra various initiatives you can take to maximize your engagement’s success.

Let’s examine two key areas of knowledge and documentation that we find lead to greater success: your quality assurance (QA) processes and your environment’s architecture.

Document Quality Assurance Procedures

Most organizations have some form of quality assurance procedures in place for the applications they develop and the infrastructure they build and maintain. However, the process documentation is often sparse or non-existent. Knowledge of the organization and its environment, or particular quality assurance team members, tends to be highly relied on to ensure applications meet the agreed standard.

Haphazard documentation makes it challenging for new staff to understand how everything works. Plus, when you engage partners like Mission, we need to spend a bit more time understanding your environment before we can implement additional benefits.

It’s essential to document your quality assurance processes as thoroughly as possible to ensure your applications and services meet user expectations. Documentation also enables your AWS partner to operate in an Agile manner and make changes without fear of breaking your applications. Let’s explore three key areas that benefit from strong documentation.

QA on Deployed Applications and Services

To ensure your applications perform for your users in production, you naturally understand and test the components as they run and interact with each other. An excellent place to start your documentation is to create a simple set of user stories explaining how your applications and services should perform in response to user actions in your current production environment.

The quality assurance practices you’ve already used as part of your application and service deployment processes form the documentation to share that understanding. For example, you could confirm that a user goes to the products section and sees 20 product images rendered using the current application.

Capturing these straightforward yet essential user expectations and understanding which applications and services are deployed within your AWS environment allow partners like us at Mission to gain a clear understanding quickly.

QA on Provisioned Infrastructure and Templates

Infrastructure-as-code (IaC) templates can also help describe the intended environment if you’ve configured and deployed your infrastructure using code. Additionally, many tools allow you to build visualizations and scan for vulnerabilities, quickly enabling specialists unfamiliar with your environment to gain great insights.

Even if you don’t deploy your infrastructure as code, your quality assurance documentation can still provide insights into your environment. When your environment is running, or when you add new infrastructure, the steps you perform to verify that infrastructure is provisioned and running as expected help document your environment’s configuration.

CI/CD Pipeline Steps and Automated QA Tests

Finally, the way you build, test, and deploy your applications through the CI/CD pipeline can reveal the components you deliver as a result and how your applications add new components. For instance, say you add a new build component, test cases, or additional deployment steps. Document procedures you follow to verify that those components are performing as expected. This documentation can further increase your environment’s visibility.

Automated testing is ideal because tests run quickly. However, manual tests are much better than no testing at all. Sometimes it also makes sense to manually test apps before automating your QA later, as manual testing documentation provides a high level of detail that you can reuse.

This detailed documentation also gives new staff or partners insight into how your applications change. This insight ensures work can proceed without affecting your development schedule and sets expectations for change during long-term engagements.

Create Comprehensive Architecture Diagrams

Documenting your quality assurance procedures can provide some good benefits when you engage a technology partner. It can be pretty obvious how they can reuse this documentation. Still, architecture documentation is a bit harder to sell — especially in Agile environments with a tendency to try different approaches and move quickly.

But architecture documentation and diagrams help others understand the larger environment and ensure your Agile teams appreciate the broader picture. Whether it’s already in the cloud, on-premises, or a hybrid environment, clearly defining and documenting your application and infrastructure’s current architecture enables a partner like Mission to understand your environment. This understanding helps your partner accelerate your adoption, deploy various workloads, and improve your cloud environments’ security and performance.

There are many ways you can develop your architectural documentation. These methods include manually keeping diagrams and documentation while planning and implementing your application components.

If you’ve already deployed workloads to AWS, you can also leverage tools to diagram your current architecture, like Hyperglance and Cloudcraft. These tools maintain an up-to-date, accurate view of your AWS environment without you manually creating diagrams from scratch. Even if you have a hybrid environment or your architecture diagrams are incomplete, these tools can provide helpful information and reduce the ramp-up time.

If you don’t have any architectural diagrams or documentation and don’t even know where to begin, Mission can still help. However, you will need to plan for additional ramp-up time while we leverage auditing and interviews to build a detailed understanding of your architecture.

Even building simple architectural diagrams of the high-level components, and outlining how they interact, can aid our engagement while providing your Agile teams with a broad understanding of your environment. You can start small by documenting and diagramming the architecture of the components you are designing and developing right now. This quickly progresses your documentation work and adds value to your operations.

Next Steps

Documentation is an important aspect of understanding your environment. It helps cloud partners like Mission and your internal Agile teams.

Devoting time and resources to documentation can sometimes feel like wasted effort, but this process doesn’t need to be onerous. Incorporate documentation steps into your existing CI/CD pipelines when you enact quality assurance processes and build out architecture diagrams when designing and deploying your environments. Even starting small can help all parties begin to understand the broader context.

If you don’t have these processes in place already, or the task seems too large to undertake, Mission can still help you get the most out of your cloud environment. We work with you to build out your environment’s architectural diagrams and documentation, increase your security posture, and optimize your environment for performance or cost.

We can be that specialized extension to your IT department so you can focus on delivering value to your clients. Get in touch with our Cloud Advisors to discover how our partnership helps fully build your DevOps practices on your success.