Skip to content

Challenge 2 (Setting up development workflow)

Steve Yi edited this page Feb 10, 2022 · 1 revision

Setting up development workflow Resist the initial temptation to rush to the keyboard! This is the time to pause and think as a team about your end-to-end deployment process that you would implement in this company.

Reminders:

Use an InPrivate/Incognito window in your browser to avoid any confusion with any other credentials that you may use to access Azure resources. The credentials you need to access the Azure subscription assigned to your team are available on the “VIEW LAB ENVIRONMENT” tab. Additional credentials for your teams deployed resources can be obtained following the instructions on the Overview tab under the section “Cheat sheet for the DevOps OpenHack”. Once you have configured your Git repository you may see security alerts if you are an administrator in your GitHub organization. Do not be alarmed, these are intentional and you will be required to resolve security issues in a later challenge. Prior to the event, the full solution was deployed to Azure with the following resources:

A single Azure App Service on Linux service plan The team website, Tripviewer, that your customers are using to review their driving scores and trips which are being simulated against the APIs Four APIs each deployed to their own Azure Web App for Containers instance which is associated with the existing App Service plan A single Azure SQL server and database which host a database named mydrivingDB The architecture is depicted in the following diagram:

DevOps OpenHack architecture DevOps OpenHack architecture The code and tests for the APIs are available in the following GitHub repository:

Azure-Samples/openhack-devops-team Challenge Select the tooling that best fits your team’s skills or learning plans, and configure and implement the mechanisms that will form the basis of the development workflow. You will need to set up the mechanism to link the code changes to your backlog, to prevent people from directly changing the code in your main branch without peer-reviewing (including code ownership for to establish mandatory reviewers). You are not expected to touch the code, nor automate the build process; this will be required in the next challenge.

Create your own code repository either by forking the provided repo on GitHub or import into GitHub.

Note: Downloading and extracting an archived version of the repo locally (instead of forking) if you are following the GitHub route may be beneficial as it will narrow down the choices that your team will need to make when you are in the process of creating Pull Requests against your default branch.

If you choose to use Azure Pipelines, you will later be required to establish automatic links between a given build and its corresponding work items. In addition, you will need to use setup your repository as Private, setup DevOps Organizational billing with your Azure Subscription, and purchase parallel jobs for your pipeline(s).

Likewise, if you prefer to use GitHub Actions you will be expected to link your work items to commits as well.

Clone this wiki locally