In this section, we discuss one possible approach to delivering software via DevOps . It is important that you understand this so that you can see why we do what we do in our DevOps Lab. The diagram below depicts our DevOps implementation, and we will be referring to this diagram throughout the lab articles.
Sports Store runs completely in Azure. The app service, database, and other Azure infrastructure elements are defined in the source code and saved in version control. This approach is known as Infrastructure as Code and is a key part of a DevOps implementation. Since we are using a cloud-based solution, it is very easy for us to provision environments. Since everything is defined in the source code, provisioning an environment can be done in a snap . We use the following environments:
- Production – The code base from the master branch is deployed here on demand. This is the environment used by our end users.
- QA – The code base from the sprint branch is deployed here. This is done on demand by the software engineers conducting the testing.
- Build – Each night, the code base from the sprint branch is deployed to this environment. Integration tests are run here, since this environment allows them to hit infrastructure. Automated QA tests are also run nightly in the build environment.
VERSION CONTROL AND BRANCHES
We follow an Agile approach using Scrum and two-week sprints. We typically release a version at the end of each sprint.
We use Git for our version control. The master branch is where our production code resides, and we have a branch for the current sprint. When the sprint ends, we perform a pull request from the sprint branch into the master branch.
Each user story has a branch as well. When a developer has finished working on a user story, a pull request is made into the sprint branch.
SOFTWARE DEVELOPMENT AND TESTING
When work is begun on a story, a new branch is created from the current sprint branch. All development is done on the developer's local workstation, including the development of unit and integration tests.
A Unit Test is a quick running test that is typically mocked so it can run quickly. Integration tests are implemented using the unit test framework but typically include infrastructure such as the database. Integration tests are run nightly.
When a story is ready for QA testing, a pull request into the sprint branch is made. This is where peer code reviews are conducted.
Once the pull request is approved, the code is merged into the sprint branch, and the continuous integration build is invoked. Any broken unit tests are addressed at this point.
The story is tested in the QA environment. The product owner reviews the story implementation as soon as possible. If there are issues to address, the developer makes the required changes.
At the end of the sprint, a pull request is made from the sprint branch to the master branch. This gives the team the chance to review all code that was changed in the sprint.
MANUAL AND AUTOMATED TESTING
As the sprint progresses, a set of manual tests are written. These tests are attached to the story as a Word document.
NOTE: We use Word for our testing to keep costs low. Microsoft does offer a Test Case framework, but it is quite expensive, so we use Word.
Stories are tested during the sprint and are considered part of the Definition of Done.
A suite of automated regression tests are maintained as the sprint unfolds. Over time, the automated regression tests grow and become an important part of product quality.
We use Selenium as our automated testing framework because it is open source. We use Azure to host our automated QA test execution agent.
BUILD AND RELEASE PIPELINES
This is where we implement Continuous Integration and Conterminous Deployment.
A build is configured for the master and sprint branches. The build receives the latest version of the source code, compiles it, and creates artifacts. These artifacts are used to release into various environments. We do not deploy from version control; we deploy using artifacts. Builds also run unit tests.
Each release uses a version number. We use Semantic Version numbers, which gives us version numbers like 1.0.2. Each time a build is run, the build number is incremented and added to the end of the version number. Using the example above, the fifth build would result in a version number of 220.127.116.11. This version number is displayed on the user interface of Sports Store.
This means that we always know the version of the software we are running and can trace it back to version control.
We support Zero Downtime releases using Azure Deployment Slots.
We will present an example of fixing a bug in the system as we further explore the Lab. The team is currently working on this bug in Sprint 13. The Sports Store application is available here.
We will start exploring the Lab by reviewing some software development details.