Foreword

Before reading the rest of this article, keep in mind that you might have a different understanding of the terms and concepts contained therein based on your organization’s nomenclature. Regardless, the organizational methods of utility are foundationally similar.

Firstly, there is a common misconception that practicing DevOps requires specific resources such as containers or cloud providers. DevOps is an organizational cultural shift, so the practice does not require any one particular resource. However, your organization’s choice in technologies may have a positive or negative impact to your organizational culture, hence its importance.

The focus for this article will be centered on DevOps software engineering resources that should accelerate programming, version control, private Build, CI Build, Package management, and continuous delivery environments. This article will only cover the logical layer of a DevOps architecture, and will target Microsoft Azure technologies as our resource of preference.

IDE

Integrated local development environment editors are a software engineer’s tool to accelerate programming. There are a number of editors like VS Code, Visual Studio, or PyCharm that can be used. The important thing is to strike a balance and work on providing a consistent development experience. However, it is important to not discourage experimentation, which in the long run can impact employee morale. At a minimum, it should be agreed upon that too many add-on features increase complexity and overhead, mostly in the form of specialty training for non-functional requirements.

Source Control

A critical resource in our architecture is a distributed version control service, also referred to as source control. Git is an example of such a distributed version control service. Git provides a repository that is a unit of versioning, which allows you to roll back to a previous version if the need ever arises because of bugs or other code build issues. All application resources should be stored in source control.

Private Build

The next component in our architecture is the private build. The private build is the foundation for the continuous integration build. This component in the software development life cycle is where we start automating unit and integration tests. If the private build adheres to your organization’s software protocols, then we commit our changes and push them to the continuous integration build service, like Microsoft Azure Repo.

Continuous integration

Azure Repo is Microsoft Azure’s cloud scaled Git repository and supports continuous integration. Azure repo will be our first centralized assurance gate. Azure repos can provide static and dynamic code analysis, vulnerability scans, testing, and enterprise scale collaborative pull requests. Azure repo features include build pipeline agents that provide continuous automated tests, package management, and build management. This is separate from the local developer’s workstation, away from any environmental configurations. Organizations determine required configurations on the Azure DevOps service for the software. It is absolutely necessary that your package contains everything to provision, configure, and install the software in the release stage later on.

Package Management

Your organization will create hundreds of release candidate packages and you will require a place to store these software packages reliably. Azure Artifacts provides NuGet services for package management, which includes features like versioning and access over secure API’s.

Continuous Deployment Environments

There are several noteworthy environments in our DevOps pipeline, such as the TDD environment. Builds are automatically deployed to this environment. The environment is automatically created and destroyed during build testing, without human interaction. TDD runs many tests like, UI tests, system tests, load tests, security tests, etc. This environment assures you that you can recreate your solution at any time.

Of course, there is still a human aspect to the process, and many organizations utilize manual testing environments for QA as well as user acceptance testing. Manual verification is critical, and the feedback provided enriches the organizational goals, which is delivering value via software.

The final environment is known as production. In this environment, you will make sure that you are not doing anything new and simply executing on your testing and experimentation. This environment has many similarities to the Manual testing environment in terms of configuration and implementation. Every strategy and compliance measure you utilized in the manual testing environment will be duplicated here to ensure a stable successful release of software.