Our Continuous Delivery Approach
At Clearly Agile, we utilize Microsoft Azure as our platform for Continuous Integration, Continuous Delivery, and Release Management activities because of its very low barriers to entry and extremely robust set of tools and services. The purpose of this information is to provide a high-level overview of what works for us so that (1) you will have greater confidence in partnering with us for solutions and consulting / training services and (2) you can easily recognize that organizations of any size (startups to large heavily regulated agencies) can get started with very minimal investment.
Where possible we added hyperlinks so you can attain additional information. Please do not hesitate to contact us for clarifying information or if you simply want to chat about getting started with your own cloud-based Continuous Delivery / Deployment framework.
(Coming Soon! Image of our Continuous Deployment Framework)
We leverage Microsoft Office 365 E3 for our productivity suite (Microsoft Office) along with Azure Active Directory Basic IUR and Enterprise Mobility + Security E3. This combination provides us with the ability to provide our employees, contractors, and partners with the tools and services they need while being able to maintain a high degree of security and compliance no matter what device they use for any of our collaboration, development, testing, and delivery / deployment needs.
Easy but Secure Access
Utilizing single-sign-on (SSO) across our tools (Microsoft Office, SharePoint, Azure, Environments, GitLab, SonarQube, etc.) simply just makes it less burdensome and secure. We utilize a centralized access approach across all of the services that allow it via Lightweight Active Directory Protocol (LDAP) and Active Directory Federated Services (ADFS).
Traceability and Transparency
By leveraging Active Directory services from end-to-end (developer requirements to production deployment) we are able to see who did what and when. Below are the activities and tools that leverage SSO.
|Requirements Management||GitLab Enterprise Edition|
|Source Code Management||GitLab Enterprise Edition|
|Build and Package||Jenkins 2.x|
|Continuous Integration||By default with above tools|
|Continuous Delivery||By default with above tools|
|Continuous Deployment to Lab||By default with above tools|
Culture Snippet: Please note that our culture does not utilize this information for punitive reasons but rather to see what we may need to automate, harden, or train on. This is vital if to create a DevOps culture
Source Code Management
GitLab Enterprise Edition is our choice for source code management because of its capabilities, low barrier to entry, and ability to integrate with our other tools and services. In regards to implementation, we have a dedicated Linux-based VM within our Azure instance.
Choosing GitLab EE was easy because its core capabilities appear to have been influenced by a DevOps mindset. It is a best of class source code management tool but also including requirements management, dashboards, reporting, a Continuous Integration engine, and Continuous Delivery engine really set it apart from other Source Code Management (SCM) tools.
The low barrier to entry is because of the nominal per-user fee on an annual basis and the Linux VM to that hosts it. To reduce our monthly VM cost by about 75%, we keep the VM offline except when needed. Using the requirements management aspect of GitLab EE has allowed us to eliminate costs we would normally incur with a requirements tools like Agile Central (Rally), VersionOne, JIRA, or Team Foundation Server (TFS).
The ability to leverage Active Directory is ideal for us because of its SSO capability for ease of use, transparency of knowing who did what and when to traceability from requirements to code check-in to delivery to other environments.
For CI, we utilize GitLab Enterprise Edition and Jenkins vice Visual Studio as we want to ensure that any change to the repository causes the process to automatically trigger. Essentially Jenkins has a GitLab plugging that constantly polls our repositories and starts a CI process whenever a change is detected.
In case you are wondering why we chose Jenkins over the CI capability with GitLab EE it is because we felt that Jenkins was more mature, more of a standard, and it has such a mass amount of plugins there would be more flexibility and scalability.
Our CI process is simple; do a quality check, build and pack if good to test environments, utilize the built package to push to our lab environment for the specific web application.
Building quality-in is a tenant of DevOps and is the mindset we have at Clearly Agile. We believe in a test-first mentality because developers should be preventing bugs vice finding them.
As we favor the .NET technical stack we utilize NUnit for our unit and integration tests. We strive for 80% unit test code coverage for new and refactored code and collaborate on the right amount of integration testing to automate. During the initial Continuous Integration process, we break the build whenever a unit test or integration test fails.
If there is no issue with unit and integration tests, the next step in the quality process is to perform Static Code Analysis (SCA). We have chosen SonarQube as our SCA tool because it integrates with the rest of our technology stack. We do not break the builds upon findings from a SCA but we do require a review of its findings after code is pushed to the mainline. We are actively investigating how to break the build whenever SonarQube finds blockers or critical because this capability no longer exist in version 6 and greater.
To help prevent findings with SCA, our developers utilize SonarLint within Visual Studio because it detects the same sort of findings SonarQube would find but in real-time (as they are coding).
Build & Package
After the quality activities execute, our build process either stops because of poor quality or completes. If the build is successful, follow-on activities bundle everything up and push the package to a repository for future use. FYI: We do not account for rollbacks as instead we rather just address the issue and get the update to our customers as quickly as possible.
Our CI process is crafted to know a package was created and successfully delivered to a repository in order to allow us to have a Continuous Delivery process. The process blows away any previous instance of the web application and installs the new one.
Continuous Deployment to the Lab
The last major set of activities in our Continuous Integration process is to deploy a good build and its artifacts to a lab environment for that particular web application. For example our Lifecycle Sleuth (LS), upon each successful build, has the new version pushed automatically to ls.clearlyagile.com.
We host our web applications off of our primary Internet domain because of a near-zero cost and no service level agreement to be held to. This hybrid approach allows us to forego the cost we would have incurred with an Azure VM running 24 x 7 x 365.
Open Source Databases for Building & Testing – PostgreSQL
We have chosen PostgreSQL as our database of choice for our development and test ecosystem because of its affordability (its free!) and native compatibility. Both SonarQube and Jenkins utilize PostgreSQL.