Microsoft has been renaming their online code storage and DevOps tool for a while now. When I started working with the online version of TFS, it was called Visual Studio Online. Azure VSTS and Azure DevOps are the names for the same product that Microsoft offers software development teams. Azure VSTS is an online service. The offline and on-premises version of Azure VSTS is now called Azure DevOps Server.
8 Learn more about the product offering at https://cloud.google.com/jenkins/.
9 Learn more at https://bitnami.com/stack/jenkins/cloud.
The complete installation guide is available on Microsoft’s official documentation for the Azure DevOps Server, at https://docs.microsoft.
com/en-us/azure/devops/server/install/single-server?view=azure- devops.
For the best experience with Azure DevOps, I highly recommend using the hosted version. The integration capabilities of hosted Azure DevOps are way better than the licensed copy of the server. As discussed in the previous product (Jenkins), the hosted edition also provides extra IT support to indie developers in terms of the following:
• High availability for the build environment.
• Backup and restore capabilities.
• Build environments for your runtimes. Azure DevOps supports MacOS machines that you can use for your Xamarin projects to create iOS artifacts.
• Microsoft Azure integration for microservices and web applications developed using .NET Core SDK.
• Templates created for build and release pipelines.
You can use templates on the offline edition as well, and you can connect to Azure infrastructure to deploy the solutions on the cloud. The benefits like the MacOS and Linux VMs outweighs the other downsides.
The hosted edition also comes with HTTPS, so you know that your data is encrypted. Azure DevOps hosted or on-premises is a product by Microsoft that offers built-in support for CI/CD as well as testing that can help you enforce code policies. Each job that runs on the runners is a fresh copy of the virtual machine or Docker container giving you a control over the build environment. You run the scripts (as shown in different sections for CI and building) to download and set up the required build packages.
For open source projects and build tools—such as the .NET Core build Docker images and SDK—you can download them from public
repositories with HTTPS or SSH. For custom solutions, you can create and build your own repositories. Azure DevOps will enable you to add custom repositories to your build pipelines. The goal is to increase the transparency in the build pipeline to prevent malware or code exploits.
Azure DevOps offers a comprehensive identity management solution.
It comes integrated with Azure AD and provides organizational-level user database management. You can protect your projects from unauthorized access, modifications, and commits using Azure AD identity management.
Different levels of roles in the Azure AD offer broader control over the repository and project. Open source projects can utilize this feature to offer a read-only state to everyone on the Internet but grant minimal access to external contributors.
Azure DevOps is integrated with Microsoft Azure, thus offering all the services from the Azure platform. You can, for example, use Azure Key Vault to securely store the passwords, API keys, certificates, and sensitive information on the Azure platform and use it in your build pipelines.10 Microsoft has security and privacy information that you can review to understand how you can secure your repository and its visibility. DevOps tools can only play a small part in the overall security of your project and that starts with user identity management. Azure DevOps takes care of that in every aspect of the tooling. Your users, based on their roles, are offered the products and projects they have access to.
Your stakeholders, for example, do not have write access to your repositories, but they can collaborate in the Kanban boards. They can create branches and tags but they have no access to private repositories.
You can tailor these policies per projects or per repository from the settings panel. If you take the installation on-premises, then you have more control
10 Read about Azure Key Vault integration with Azure DevOps at https://
docs.microsoft.com/en-us/azure/devops/pipelines/tasks/deploy/
azure-key-vault?view=azure-devops.
over how the repositories are accessed, as you can include the server identity management tools such as Windows Server Active Directory and other tools.
Azure DevOps is also compliant with GDPR and CCPA. Azure DevOps secures your repositories and projects from accidental data deletion by taking regular backups. You can specify where to keep the backups during the installation phase. If you are using hosted service of Azure DevOps, Azure DevOps11 will ask you where you want to keep your project.
GitLab Auto DevOps and GitHub Actions
The previous two DevOps tools are the market leading software packages for CI/CD and build environments. They provide all the features and support an organization needs to manage their software, from a small- sized company to an enterprise organization. Now, I can also discuss the offerings for the indie developers or small-scale teams that are growing to become organizations.
GitLab and GitHub are two12 names that come to everyone’s minds when they think of online code storage and collaboration. They offer similar features and options. If you find a feature on one of these platforms, you will find a similar feature on the other one too. They both provide hosted as well as on-premises support for their DevOps tools. So, in the following paragraphs, if I say something about one of these, you can assume it also applies to the other one.
11 Read more about how Azure DevOps asks for location information at https://
docs.microsoft.com/en-us/azure/devops/organizations/security/
data-location?view=azure-devops.
For GitLab and GitHub, you can be confident about security since they have good community support for security and best practices. GitLab and GitHub offer support to community authors and writers to write good quality documentation and tips and tricks for their customers. I have myself invested some time in writing documentation for GitLab products.
You are welcome to do so too!
I have worked with GitLab’s hosted as well as on-premises products.
Their hosted instance provides a good blend of security and features for indie developers. Currently, more than ten of my active projects are being hosted on GitLab and collaboration is smooth. GitLab uses HTTPS to enforce encryption for the data that travels on the wire from their servers to our machines. They provide good control over users who have access to the repositories. GitLab and GitHub both use Git version control. There are some commands that have a permanent impact on the repository. One such notorious command is the push command, mixed with a force flag.
$ git push upstream branch -f
This command will force the push to be done on the upstream remote’s branch, regardless of the warnings that Git has for the users.
Hosted solutions provide a configuration that can automatically protect your projects from these changes.
In the GitLab UI, this can be found under the project Settings ➤ Repository ➤ Protected Branches, as shown in Figure 5-5.
You can create any number of protected branches that you need. On GitHub, there is a similar feature but with a different default value. You can find the repository and branch protection under project Settings
➤ Branches ➤ Branch Protection Rules. You need to add the rules to configure the branches and their protection levels. See Figure 5-6.
Figure 5-5. GitLab offers the concept of protected branches. This helps protect the branch against unwanted changes from external or internal contributors
Each branch can have a custom rule that you define, as Figure 5-7 shows.
Figure 5-6. GitHub offers a similar feature as GitLab’s protected branches. GitHub uses the concept of “rules” to enforce several policies on the branches
In a nutshell, GitLab and GitHub offer the same features and support (a very) similar security program for your projects.
For cloud-hosted solutions, your data is stored on the servers of the service vendor. If your data is sensitive and private, then cloud hosting might not be a good option for you. These vendors use backup and restore Figure 5-7. GitHub branch rules, a complete list of the options
available to apply on the branch to protect against unwanted changes
options to maintain good service availability. Some vendors also use global replication to create copies of your data and synchronize it across the globe to provide better response times to teams that exist on different parts of the globe. In this case, your project will be stored on different regions and in different hard drives.
The build system security is not only the responsibility of your software vendor or the IT teams. The software engineers who design the build pipeline also need to ensure that the build pipelines are of good quality.
For Azure DevOps and other tools that use YAML-based configuration, this can be managed easily. You can also enforce a standard across the build pipelines (recall the topics we covered in Infrastructure as Code). Any time a user tries to modify the build pipeline, you can verify if the changes are valid or are against the policies.
GitHub and GitLab both offer this functionality. The benefit of using a GitOps-fashion build definition is that you know how a project is verified for quality, standards, and maintenance. This is a GitLab Auto DevOps CI configuration for a ASP.NET Core 3.0 project that I am currently leading:
image: mcr.microsoft.com/dotnet/core/sdk:3.0
stages:
- ci
# Just a single job to perform everything, currently.
dotnet-build:
stage: ci script:
- dotnet restore - dotnet build - dotnet test
Since the project is currently in alpha stages, we do not need to run extensive tests. But this one single file states the jobs that will run each time there are changes in the repository. It starts with the image selection
(Microsoft’s official .NET Core 3.0 SDK) and runs the job to set up the environment. It builds the application and tests it against our own testing frameworks. You have the flexibility to add your own custom tests as well as scripts.
GitHub has recently introduced a new feature called GitHub Actions. It takes a similar approach to running integration jobs for each contribution or change in your repository. GitHub and GitLab both use YAML files to configure the integration and CI jobs. This gives your teams control over the pipeline. You can also review how the pipeline is improved or changes over time—thanks to Git version control.
One point to note is that these are not an almighty build environment.
You can use GitLab Auto DevOps and GitHub Actions for a complete DevOps pipeline. The main use of these two products it to test each change or contribution to your project for quality and stability. They act as the first barrier or border that each change must go through. If the quality goes downhill, you can always reject the changes submitted. For small-scaled businesses and organizations, these tools are more than enough to host a build environment.
• They are cloud-hosted and integrated with your version control repositories.
• They are scalable and available for your software engineers with little to no configuration on your part.
• They provide Windows and Linux virtual environments to run your build, artifact and archiving jobs, testing, and QA workloads.
• They offer a suitable quota for free users too. GitLab, for instance, offers 2,000 free build minutes each month for your account or projects (if they are created separately as a group). The build minutes are similar for hosted Azure DevOps, and the same for other cloud-hosted
• They offer good integration with issue boards, build reports, software quality, and other reports. This gives a good overview for the good practice of DevOps.
If you are a startup, I encourage you to try GitLab and GitHub DevOps products before you try to create your own build infrastructure.