Blog / Microsoft Azure

Practice Effective DevOps with Azure DevOps

LOGAN RAKAI – MARCH 30, 2020

Azure DevOps is a suite of services that collaborate on software development following DevOps principles. The services in Azure DevOps are:

1. Azure Repos for hosting Git repositories for source control of your code
2. Azure Boards for planning and tracking your work using proven agile productivity tools
3. Azure Pipelines for continuous integration and delivery of your software
4. Azure Test Plans for testing your software
5. Azure Artifacts for publishing software packages

There are different plans available for using Azure DevOps. There are generous free limits that allow you to get your hands dirty and try out a lot of
what Azure DevOps has to offer. Rather than just tell you about Azure DevOps, you will see first-hand how Azure DevOps works and what you can
use it for in this post.

You will use services within Azure DevOps for everything in this demonstration. However, you can pick and choose the pieces you want to use and
integrate them with external tools that you may already be using. Azure DevOps was built to support that level of customization and you will see
several places where you have options to integrate with tools outside of Azure DevOps.

Creating Your Azure DevOps Project

Introduction
Azure DevOps services are accessed through Azure DevOps projects. Each project is part of an Azure DevOps organization. You can manage
settings shared across all projects at the organization-level and manage finer-grained controls at the project-level. This demonstration focuses on
the project level. You will create a basic plan Azure DevOps project now which automatically creates an Azure DevOps organization. The basic
plan includes access to four Azure DevOps services:

1. Azure Boards
2. Azure Repos
3. Azure Pipelines
4. Azure Artifacts

There are limits to what you can do with the services in the basic plan but it is entirely free if you have 5 or fewer users. Everything you will do in
this demonstration is well within the limits of the basic plan so follow along without worry. Delete the organization once you are finished and you will
not have any charges to worry about. The instructions below create a new Microsoft account to avoid incurring charges on an existing Azure
DevOps organization you may already be a part of.

Instructions
1. Navigate to dev.azure.com.

You can find a summary of each tool in the Azure DevOps suite from this page as well as the links to create an account or to sign in.

2. Click Start free to begin registering your account.

You can also click Sign in to Azure DevOps if you have an existing Microsoft account that you want to use. If you are currently signed in to a
Microsoft account you will be able to select that account rather than creating a new one if you choose.

3. Click Create one to create a new account:

Notice you can also directly Sign in with GitHub accounts.

4. Click Get a new email address:

5. Enter a value for New email and click Next:

6. Enter a password and click Next:

7. Solve the challenge to confirm you are not a robot and click Next to create your account.

You are automatically taken to the Azure DevOps registration process.

8. Select your Country and click Continue:

This kicks off the process of creating a new Azure DevOps organization with a name based on your email address. Your organization is a container
for your DevOps projects. The free tier limits for Azure DevOps apply to the organization as a whole and not each project if you have multiple
projects.

9. Enter a name for your project and click Create project:

It is possible to create Public projects. Public projects allow anyone read-only access to the project. Only invited members can view private
projects. Members are added to either type of project with permissions assigned to control their level of access. It is possible to change the project
visibility after the project is created (unless you disable public projects in your organization settings).

Your project Summary view is displayed once the project is created:

The project automatically adds you as the only member of the project.

Summary
You have created an Azure DevOps project using a shiny new Microsoft account. The project is running for free under the basic plan.

Adding an Azure Repo to Your Project

Introduction
Azure Repos are Git-based repositories in the Azure DevOps tool suite. You can have an unlimited number of private Git repos for free. On top of
the Git repository is an array of features to integrate repos with workflows and making it easier to manage your code and related processes. Some
of the features include pull request-based workflows, branch policies to enforce high quality of merged code, and semantic-aware code search. As
a Git-based repo, you can use all of your favorite tools that support Git with repositories in Azure repos. You will create a private repo in your Azure
DevOps project now.

Instructions
1. Click Repos in the sidebar:

The options available to you for starting the project’s currently empty repo are described:

You will import a repository to stay focused on Azure DevOps. You could also use your favorite integrated development environment (IDE) with Git
support to directly connect with your repo by cloning or pushing an existing Git repository.

2. Click Import.

3. In the Import a Git repository blade enter https://github.com/cloudacademy/example-git-repo.git as the Clone URL before clicking Import:

Besides importing Git repositories, there is also built-in support for migrating Team Foundation Version Control (TFVC) to Git.

In a few moments, the repository is imported and the Files view appears:

The repo is a static website consisting of HTML, CSS, and JavaScript files. The Repos UI allows you to view/edit files, visualize commit history,
compare branches, manage pull requests, and just about everything you’d expect from a full-featured Git repository. You will work with branches
and pull requests later on.

4. Click Commits in the sidebar.

Observe the commit graph and see how it visualizes the update title commit on a separate branch and pull request to merge it into the master
branch:

5. Click the update title commit to view the file diff of the commit:

Feel free to roam around the Repos UI to discover more of what you can do.

Summary
You now have a private Git Repo hosted in Azure Repos. You have seen some of the nice interface features in Azure Repos and you will see how
nicely Azure Repos integrate with other Azure DevOps services in what follows.

Tracking Your Work with Azure Boards

Introduction
Azure Boards provide tools for planning, tracking, and collaborating using agile tools. Boards support several processes including Scrum and Agile.
Each process can plan and prioritize work in backlogs, keep a limit on work in progress on kanban boards, organize and track work in sprints, and
use analytics to optimize your agile processes. In Azure Boards, you use work items for everything you need to track. Work items represent
different types of work such as epics, issues, or tasks. Work items can also have relationships with other work items, such as parent-child. There
are a variety of views for work items. Each provides you with an optimized view for different tasks at hand. You will use Boards to plan out a simple
product launch in this demonstration.

Instructions
1. Click Boards in the sidebar:

This takes you to the Work items view:

This view allows you to find recently updated work items. At this point, there are no work items on your board. The other board views give you
different ways to view and organize work items. You can add work items from all but the Queries view. You will begin by adding work items to a
backlog and then visualizing the work on the kanban board.

2. Click Backlogs:

With the default configuration for a project following the basic process (other built-in processes in Azure DevOps are Scrum, Agile, and CMMI)
there are backlogs for Epics and issues. If, for example, you configured the process for the project to be Scrum, there would be feature and
backlog items backlogs.

3. Ensure Epics is selected in the drop-down menu and click New work item.

4. Enter Product Launch as the title and click Add to top:

You will make an epic for the launch of a website. You will create two child work items in the epic for the work required to launch.

5. Click the Product Launch title to edit its details:

Take a moment to observe what functionality is available in the details view:

You can add a Description, prioritize, schedule, comment, post comments in the Discussion, add attachments, set the State, assign an Iteration,
among other things.

6. Set the following values before clicking Save:

Click Unassigned in the drop-down menu and assign the epic to yourself
Set the Start Date to today
Set the Target Date to tomorrow

7. Under Related Work, click Add link > New item:

You will now add the tasks required to complete the launch epic as child items.

8. Set the following values in the Add link form before clicking OK:

Link type: Child

Work item type: Task
Title: Update website content

Notice the variety of Link types available to you for describing relationships between work items.

9. In the Task details pop-up, set the following values under Planning before clicking Save & Close:

Activity: Development
Remaining Work: 2 (the units of work represent hours by default)

10. Add a second related child item of the epic that is a Task named Create release pipeline and set the following Planning properties:

Priority: 1
Activity: Deployment
Remaining Work: 3

You will create an Azure Pipeline to deploy your website using containers and before customizing the website content.

11. Click Boards and ensure Epics is selected in the drop-down menu:

The basic process template uses a simple three-state board: To Do, Doing, Done. Other processes have different default states and you can
always customize to best suit your team’s workflow requirements. For example, adding a review or test state. Following the kanban tenet of limiting
work in progress, the Doing column shows 0/5 representing a limit on the number of items in the Doing state at any given time. You can customize
the work in progress limit in the board settings .

12. Drag the Product Launch epic to the Doing column and observe the work in progress increments to 1/5 and the card’s state changes
to Doing:

You will now focus in on the tasks related to the epic in the sprint view.

13. Click Sprints:

Only Sprint 1 is available and that is all you will need for this example. To get the benefit of analytics you will need to configure a few sprint
properties.

14. Click No iteration dates in the upper-right corner and set the following values before clicking Save and Close:

Start date: Select today from the calendar

End date: Select tomorrow from the calendar

That is enough to get started. You are able to set capacities of team members for each activity type and include days off to increase the accuracy
of analytics.

15. Click Taskboard and drag the Create release pipeline task to the Doing column:

You will start working on the release pipeline next.

Summary
You have created an Azure Board for a product launch. You saw how to populate a backlog, keep track of work in progress on the kanban board,
and organize work items into a sprint. The default basic process is simple and easy to get started with although other processes are supported
and there are many ways to customize Boards to fit your own work requirements. You will see later on how other Azure DevOps services directly
integrate with Boards.

Creating a Build Pipeline in Azure Pipelines

Introduction
Azure Pipelines is the Azure DevOps service for continuous integration and continuous deployment. At a high-level, there are two distinct types of
pipelines in Azure Pipelines, which can be confusing if not made aware of early on. There are build pipelines, sometimes referred to simply as
pipelines in the UI, and release pipelines. The build pipelines are focused on the continuous integration of source code while release pipelines are
focused on continuous deployment. Although build pipelines can also deploy code, they should only be used to deploy to development or test
environments. Your production deployments are better performed using release pipelines.

Build pipelines connect to a code repository and perform a build to produce build artifacts. You will see how build pipelines are a generic tool that
can integrate with any Git-based repository and can satisfy any of your build requirements. The build is described in a YAML file that is included in
the repo. You will perform a simple build that archives the code in your Azure Repo.

Instructions
1. Click Pipelines in the sidebar:

2. Click Create Pipeline.

This kicks off the build pipeline wizard.

3. In the Connect step, select Azure Repos Git for the source of your code:

Not the other sources that can be integrated with Azure Pipelines. Azure DevOps makes it easy for you to use just what you need in Azure
DevOps and allows you to continue using whatever external tools work best for you. There is also the option to Use the classic editor for a
graphical interface although YAML build pipelines are recommended.

4. In the Select step, choose your repo.

5. In the Configure step, click Show more to reveal all the template pipelines available.

There are templates targeting Windows, Linux, and Mac platforms, a wide variety of programming languages, and container platforms:

6. Click HTML.

The HTML pipeline template appears in the Review step:

The “build” for the static website repo is simply to archive all of the files but it is enough to illustrate how the YAML pipelines are constructed:

trigger: This section specifies which events trigger a build. The default is any push to the master branch triggers the pipeline. You can configure
pushes, pull requests, and scheduled triggers. Removing the trigger list causes any push or pull request to trigger a build.
pool: Specifies which build agent pool to use. You can use Microsoft’s Windows, Linux, and Mac agents or your own self-hosted agents. In the
template, the latest ubuntu agent hosted by Microsoft is used.
steps: describe the individual tasks and their order in the stage of the pipeline. The template includes a task for archiving/zipping the files
(ArchiveFiles@2) and one for publishing the build artifacts (PublishBuildArtifacts@1) which is the zip file in this case. There is a catalog of
built-in tasks covering most build scenarios and includes PowerShell and shell script tasks to run arbitrary commands. You can also add custom
tasks if the need arises.

You can reference the pipeline schema documentation to learn about all the capabilities of YAML pipelines including variables and multi-stage
pipelines.

7. Click Show assistant to reveal the assistant that allows you to easily add additional steps without writing any YAML.

Browse through the available tasks but don’t add any to your pipeline.

8. Delete the trigger list so any push or pull request triggers a build and click Save and run:

9. Click Save and run in the commit blade:

This will commit directly to master. You will see an example of the branch and pull request flow later on.

The build is queued and usually begins running within a few seconds. Once completed you can see the Success status and 1 published build
artifact:

Clicking the Job reveals the build steps and associated logs. Clicking the 1 published artifact reveals the published zip archive. This artifact can
be used to trigger a release pipeline, which you will see next. It is also worth noting that these build artifacts are different from Azure Artifacts,
which appear in the Artifacts sidebar. Azure Artifacts are part of Azure DevOps devoted to publishing NuGet, npm, and Maven packages.

Summary
You have defined a build pipeline for your codebase in Azure Pipelines. Although you used an Azure Repo, any Git repository can be used with
Azure Pipelines. You saw how flexible the YAML pipelines are and can include a variety of step types for whatever your builds require. You will see
how release pipelines differ from build pipelines next.

Creating a Build Pipeline in Azure Pipelines

Introduction
Azure Pipelines is the Azure DevOps service for continuous integration and continuous deployment. At a high-level, there are two distinct types of
pipelines in Azure Pipelines, which can be confusing if not made aware of early on. There are build pipelines, sometimes referred to simply as
pipelines in the UI, and release pipelines. The build pipelines are focused on the continuous integration of source code while release pipelines are
focused on continuous deployment. Although build pipelines can also deploy code, they should only be used to deploy to development or test
environments. Your production deployments are better performed using release pipelines.

Build pipelines connect to a code repository and perform a build to produce build artifacts. You will see how build pipelines are a generic tool that
can integrate with any Git-based repository and can satisfy any of your build requirements. The build is described in a YAML file that is included in
the repo. You will perform a simple build that archives the code in your Azure Repo.

Instructions
1. Click Pipelines in the sidebar:

2. Click Create Pipeline.

This kicks off the build pipeline wizard.

3. In the Connect step, select Azure Repos Git for the source of your code:

Not the other sources that can be integrated with Azure Pipelines. Azure DevOps makes it easy for you to use just what you need in Azure
DevOps and allows you to continue using whatever external tools work best for you. There is also the option to Use the classic editor for a
graphical interface although YAML build pipelines are recommended.

4. In the Select step, choose your repo.

5. In the Configure step, click Show more to reveal all the template pipelines available.

There are templates targeting Windows, Linux, and Mac platforms, a wide variety of programming languages, and container platforms:

6. Click HTML.

The HTML pipeline template appears in the Review step:

The “build” for the static website repo is simply to archive all of the files but it is enough to illustrate how the YAML pipelines are constructed:

trigger: This section specifies which events trigger a build. The default is any push to the master branch triggers the pipeline. You can configure
pushes, pull requests, and scheduled triggers. Removing the trigger list causes any push or pull request to trigger a build.
pool: Specifies which build agent pool to use. You can use Microsoft’s Windows, Linux, and Mac agents or your own self-hosted agents. In the
template, the latest ubuntu agent hosted by Microsoft is used.
steps: describe the individual tasks and their order in the stage of the pipeline. The template includes a task for archiving/zipping the files
(ArchiveFiles@2) and one for publishing the build artifacts (PublishBuildArtifacts@1) which is the zip file in this case. There is a catalog of
built-in tasks covering most build scenarios and includes PowerShell and shell script tasks to run arbitrary commands. You can also add custom
tasks if the need arises.

You can reference the pipeline schema documentation to learn about all the capabilities of YAML pipelines including variables and multi-stage
pipelines.

7. Click Show assistant to reveal the assistant that allows you to easily add additional steps without writing any YAML.

Browse through the available tasks but don’t add any to your pipeline.

8. Delete the trigger list so any push or pull request triggers a build and click Save and run:

9. Click Save and run in the commit blade:

This will commit directly to master. You will see an example of the branch and pull request flow later on.

The build is queued and usually begins running within a few seconds. Once completed you can see the Success status and 1 published build
artifact:

Clicking the Job reveals the build steps and associated logs. Clicking the 1 published artifact reveals the published zip archive. This artifact can
be used to trigger a release pipeline, which you will see next. It is also worth noting that these build artifacts are different from Azure Artifacts,
which appear in the Artifacts sidebar. Azure Artifacts are part of Azure DevOps devoted to publishing NuGet, npm, and Maven packages.

Summary
You have defined a build pipeline for your codebase in Azure Pipelines. Although you used an Azure Repo, any Git repository can be used with
Azure Pipelines. You saw how flexible the YAML pipelines are and can include a variety of step types for whatever your builds require. You will see
how release pipelines differ from build pipelines next.

Creating a Release Pipeline in Azure Pipelines

Introduction
Although there are tasks for deploying build artifacts in build pipelines, there is more support for releases in release pipelines including automatic
rollbacks. When releasing to production environments release pipelines are recommended. You can include manual approvals and gates within a
release pipeline to protect your release environments. You will define a release pipeline that will automatically trigger when a pull request is made
to the master branch of your Azure Repo. The release pipeline with use the build artifact produced by the build pipeline as its input.

Instructions
1. Click Releases in the sidebar:

2. Click New Pipeline.

This will display a blade with a variety of templates to choose from:

Browse through the templates. You will create a simple release pipeline but know there are templates for a variety of deployments in Azure and
externally such as to a Kubernetes cluster. It is also possible to save your own release pipelines as templates and import/export release pipelines
in JSON format.

3. Click Empty job at the top of the blade to start with a pipeline without any steps defined.

A Stage blade appears with the default name of Stage 1:

You will build out the pipeline by defining the artifacts that trigger the release and add tasks to the Stage 1 job that is currently empty.

4. Click + Add an artifact and click the drop-down to expand all the available artifact sources:

The Build option is appropriate in this case because you will release using the build artifact created by the build pipeline. However, you can trigger
a deploy directly from Azure Repos. Several sources outside of Azure are also available allowing you to plug-in release pipelines with your
preferred external systems.

5. With Build selected, set the following values (leaving the defaults for the rest) before clicking Add:

Project: Select your project from the drop-down menu

Source: Select your build pipeline from the drop-down menu

The information tip at the bottom tells you the drop artifact will be used for each successful build. By default, the build artifact is named drop.

6. Click the lightning bolt on the artifact to configure a continuous deployment trigger for the release:

As an example, you will configure a deployment every time a pull request created from a feature branch. This would allow you to view a
deployment associated with a pull request to help with reviewing the code included in the pull request. You can also always manually deploy a
release regardless of the continuous deployment configuration.

7. In the Continuous deployment trigger blade, click the Pull request trigger slider and set the following values:

Target branch: master

You can also configure deployments whenever a build is available. The information tip at the bottom tells you which stages are configured to run
with a pull-request trigger. This gives you the flexibility to choose which stages run for releases triggered by a pull request. You will configure the
only stage currently available to run with the pull request trigger.

8. Close the trigger blade and click the lightning bolt on the Stage 1 element:

In the Pre-deployment conditions blade you can configure a variety of conditions to specify when the stage will execute:

Amongst other things, you can set users who are allowed to manually approve or reject deployment, use Gates, such as running a security scan,
before allowing the stage to run. You can make stages Manual only as well.

9. Toggle Pull request deployment to Enabled before closing the blade.

10. Click 1 job, 0 tasks under Stage 1 to edit the stage tasks.

11. Click Agent job and observe this is where you can configure the Agent pool, Agent specification (whether you want Windows, Linux, or Mac
for example), and whether the stage should run only when previous stages succeed, etc.

The default values will work for this example.

12. Click the + icon to the right of Agent job to open the task catalog:

There are hundreds of tasks to choose from including many from third-parties through the Marketplace. You will add tasks to download the build
artifacts and echo the title from the index.html file. Although this isn’t a real release it will illustrate how to develop release pipelines.

13. Add the Download build artifacts task followed by the Bash task:

The left stage visualization should now look like this:

14. Click Download Build Artifacts and set Download type to Specific files and leave the rest at their defaults.

15. Click Bash Script and set the Type to Inline and enter the following in the Script field:

echo 'Releasing...'
cd drop
unzip -q *
grep '<title>' index.html

This will unzip the build artifacts and echo out the <title> tag line from the index.html file. This is enough to describe the simple release pipeline, but
you will also update the pipeline’s integrations so release status details can be observed outside of Azure Pipelines.

16. Click the Options tab followed by Integrations:

By default, the deployment status is reported in the repository host (Azure Repos) interface.

17. Check each of the following before clicking Save and OK in the dialog that appears:

Report deployment status to Work (create links to all work items that represent associated changes to the source when a release is
complete)
Report deployment status to Boards and set the Deployment type to Production (work items associated with commits in the build will show
the status of the release)
Enable the deployment status badge (URL that displays a badge for the release status)

18. Click Create release to manually trigger the release pipeline:

19. Click Create to accept the release will automatically run all stages and use the latest build artifacts:

20. Click Release-1 in the notification bar that appears to view the release details:

21. Close any pop-up that appears and click Stage 1 to view its progress:

If you don’t see Succeeded within a minute, click the Refresh button.

22. Click View logs to view the agent logs:

You can view logs for each step of the stage including the two tasks you defined:

Observe the stage automatically includes a Download artifact step which is the same as the Download Build Artifacts step you added except it
downloads to a different directory (a subdirectory named after the repo). You wouldn’t need to include both in a real pipeline but it was useful for
illustrating multiple release build tasks.

23. Click Bash Script and observe the <title> output at the end of the logs:

Also, note it was no problem to run a bash script on the Windows agent.

Summary
You created a release pipeline that will trigger when pull requests are made to the master branch of your Azure Repo. The release consists of one
stage with two tasks. You saw the extensive amount of tasks that are available within Pipelines and from the Marketplace. There is a lot more to
release pipelines including multi-stage capabilities and using variables to adapt the release. You can explore more about those capabilities on your
own after the demonstration is complete.

Configuring an Azure Repos Branch Policy

Introduction
To fully support pull request workflow-based releases you need to configure a branch policy on the master branch in Azure Repos that validates
the code can build. The branch policy also allows to require pull requests for the branch and set the minimum number of reviewers, and more.
However, you will configure the master branch policy to validate the code builds.

Instructions
1. Click Repos > Branches in the sidebar.

2. Hover over the master branch and click the three dots on the right followed by Branch policies:

Observe the available policy settings before continuing.

3. Click + Add build policy to validate the code in pull requests:

4. Select your Build pipeline from the drop-down and click Save:

The default setting requires that the build succeeds to complete pull requests.

Summary
You now have a branch policy for the master branch enforcing successful automatic builds for pull requests.

Completing the Product Launch Epic

Introduction
With your release pipeline and branch policy in place, you are now ready to complete the Product Launch epic by updating the website content.
You will see how the pull request workflow works in Azure DevOps along the way.

Instructions
1. Click Boards > Sprints in the sidebar.

2. Drag the Create release pipeline card to the Done column and drag the Update website content card to Doing:

3. Click Update website content to open the card details.

You will create a branch and later create a pull request to the master branch to complete the work item.

4. Under Development click create a branch and set the following values before clicking Create branch:

Name: feature/content-update
Work items to link: Select the epic from the drop-down (the task is automatically linked)

You are taken to the Files view of the new branch.

5. Click the index.html file followed by Edit to edit it within the browser:

6. Add and Azure DevOps to the title and click Commit:

7. Link both work items to the commit before clicking Commit:

8. Click Pipelines > Pipelines to observe a new build has resulted from the commit:

9. Click Releases and observe there is no new release since only pull requests will result in an automatic release with the current configuration.

10. Click Repos to return to the content-update files view and click Create a pull request:

Notice the succeeded status telling you the build succeeded from the repo view.

11. Observe the diff view at the bottom summarizing the changes before clicking Create:

You can also assign reviewers if other members were added to the project.

12. Observe the Status section on the right which transitions through the build status and finally to New release pipeline succeeded:

This is the result of the branch policy and pull request release trigger.

13. Click New release pipeline succeeded to view the release.

14. Click Succeeded under Stage 1 and then view the updated title output by the Bash Script task:

This is enough to verify the release in this example.

15. Click Repos > Pull requests and click the only available pull request to return to the active pull request.

16. Review the tabs available in the pull request view before clicking Approve followed by Complete:

Approving automatically adds you as a reviewer.

17. Observe the different settings available before clicking Complete merge:

The default settings will cause the work items to be completed after merging and the content-update branch will be deleted.

18. Click Boards > Sprints and observe the Update website content card is in the Done column.

The epic card is also automatically moved to Done on the epic kanban board.

19. Click Update website content to view the task details and observe the release and pull request are both linked from the card because of the
integrations configured earlier:

Summary
That completes the Product Launch epic and this tour through Azure DevOps. Although this demonstration exclusively used Azure DevOps, you
are free to use the pieces that are most applicable to your needs. For example, if you like using GitHub for your code, you are free to use only
Boards and Pipelines without Repos. This high degree of configurability is also visible within each Azure DevOps service. I’d encourage you to look
at the Project Settings which are accessible at the bottom of the sidebar:

This is where you can add members to projects, configure role-based access control, and much more. You can also explore the Organization
settings by clicking the Azure Devops icon in the upper-right corner and clicking settings in the lower-right:

You can view billing, audit logs, usage, add extensions, configure your Boards process (Basic, Agile, Scrum, CMMI) and a whole lot more from
there. This is also where you can delete the organization, which is recommended once you are finished exploring.

Azure DevOps also includes Test Plans, but they aren’t included with the free plan (although you can get 30 days free). To learn more about Test
Plans check out the product page.

WRITTEN BY
Logan Rakai
Logan has been involved in software development and research for over ten years, including four years in the cloud. At Cloud Academy, he is adding to the library of
hands-on labs.