Introduction to Azure?DevOps

As Microsoft defines, DevOps is a union of people, processes & products to enable continuous delivery of value to customers.

Devops Practices include

• Agile Planning- This is a way in which a project is delivered. We can create a backlog that is transparent to the whole team and prioritize the tasks that need to be done first.
• Continuous Integration (CI) — Automate build & test functions every time a commit is made to a version control system.
• Continuous Delivery (CD) — How to test, configure and deploy from build to QA or prod.
• Monitoring — Using telemetry to improve application performance and usage patterns.

Azure Devops is a suite of services that is used for automated build processes, testing, version control and package management.

Few important Azure Devops Tools are:

• Azure Boards- Helps to plan and track the tasks with all team members.
• Azure Pipelines- Helps to build, test & deploy with CI/CD.
• Azure Test Plans- Used for manual and exploratory testing.
• Azure Repos-Similar to GitHub and provides unlimited storage for private and public git repos.
• Azure Artifacts- Used to create, host & share packages.

Getting started with Azure Devops:

• log in to dev.azure.com.
• Create an Azure devops organization.
• Create a new project inside the Azure Devops Organization.
• Set the project visibility to private or public as per your requirement. If you are willing to share your project with the community set to public, else set to private.
• While creating a project you have to choose the preferred version control and the preferred work item process.

Work Items are of four types-

• CMMI(Capacity Maturity Model Integration) - This is the highest level of work item and is used for complex projects in very large organizations.
• Scrum - This is mainly used in projects that are handled by scrum master.
• Agile - This is used in projects that are agile in nature.
• Basic - This is the simplest of all and we will go forward by choosing this one for now.

Version Control are of two types-

• Git
• Team Foundation Version Control

Next we have to create a team for the project and include the required members-

• Go to Project Settings
• Under General select Teams

By default a team will be created. You can create new teams and add & remove members as necessary.

Azure Boards-

Azure Boards provides you with a set of predefined work item types to support tracking features, user stories, bugs, and tasks. Whatever Agile method you use, Azure Boards supports you with the tools you need to implement that method.

Azure Boards mainly consists of

• Work Items — This is used as a way to track any new features, bugs, risks and issues that you are working on for a particular project.
• Boards- This is a way to view you workitems in cards.
• Backlogs — Here you see workitems in a list.?
• Sprints- This is used to define the time frame in which the workitem is supposed to be completed.
• Queries- It is used to run a simple queries on query editor to fetch data on work items. You can filter work items based to query criterias. Many work item queries are predefined with your process. Members of your team may have created shared queries that you can view and run. Often, it’s easier to define a new query by building on the query definition that’s already available to you.
• Delivery Plans- It is similar to a Gantt Chart. It provides a highly interactive calendar view of multiple team backlogs and work items across different projects.

Azure Repos-

Cloud hosted git repository where teams store and collaborate their code with pull request & advanced file management.

Azure Repo is same as github, here we can easily perform functions such as

• Clone any other repository from github.
• Commit new changes to our private repo inside azure repo.
• Create a pull request for commiting changes to your main branch.
• We can add comments, Approve and Complete a pull request from Azure repo.

Azure Repos consists of:

• Files — Shows the directory structure of your online git repository.
• Commits-This contains the commit history of you Azure Repo. Similar to git log in GUI mode.
• Pushes- Logs history of all pushes made to Azure Repo.
• Branches- List all branches in the repo.
• Tags-Use tags to mark a point in history that is relevant to the repository.
• Pull requests- All open pull requests will be shown here. This is a great tool for managing pull requests in Azure repos.

Concepts of all operations in Azure Repo are exactly the same as github with some changes in user interface. You can set up Branch Policy and Branch security in Azure Repos.

Azure Pipeline-

Azure Pipeline defines the tasks & jobs that are implemented for performing the CI/CD of your code. It is made up of one or more stages. It can be assumed as a workflow that defines how your build, test & deployment steps are run as a code.

Azure Pipelines consists of:

• Pipelines — Here you define your build, test and release jobs in azure-pipelines.yml file. From here you can run, monitor, view test results and debug the tasks and jobs of your pipeline.
• Environments- It is used to represent a group of resources for Azure pipeline. You can map dev, QA, prod. As of now only k8 clusters and vm are available and resources like db and webapps are in development.
• Releases- This is the classic GUI based release interface used for deployment. You can set up triggers, gates and approvals in CD.
• Library- Here you can create multiple variable group that is used to store values and secrets to be passed into a YAML pipeline. These variable groups can be used across multiple pipelines in that project.
• Task groups- Here you can group together a set of reuseable tasks that can be added to a build or release pipeline.
• Deployment groups- This is a logical set of deployment target machines that have agents installed on each one. They represent the physical environments, for example, “Dev”, “Test”, or “Production” environment. That is deployment group is just another grouping of agents, much like an agent pool.

While using Azure pipeline, you will come across a build agent. Which is the machine that will build, tests & deploys code to the cloud. It mainly runs tasks in the build definition (i.e. is a azure_pipeline.yml). It can be a azure hosted or self hosted agent.

Azure Artifacts-

Developers can share, publish their code and manage all their packages from Azure Artifacts in their own feed or share it with other team members. You can access packages from other’s feeds and popular registries like Nuget, NPM, Maven and others.?

Azure Test?Plans-

It is a web based test management solution within Azure DevOps for both automated and manual testing, UAT, exploratory testing and also for stakeholder feedback collection. It is a good tool for QA team for managing test plan, test suites and test cases in the software development process.

Test Plan is container for storing and grouping Test Suites which is a collection of Test Cases.

Test Suites are of three types-

• Static Based- It is a nested test suite that itself acts as a container for hosting other test suites or adhoc test cases within itself.
• Requirement Based- Here you can mention the requirement and the test suite will populate with the test cases that are tied to that requirement insted of manually choosing the test cases. This is the most simple and tracable test suite.
• Query Based- Here you need to write a query to establish a particular caracteristics that will fetch adhoc test cases that match the charateristics of the query.

Finally in Azure Devops overview we have

• Summary- Contains the project descriptions, Project stats including highlited details from Boards, Repos and Pipelines.
• Dashboards- Here we can add different widgets that showcase different data such as Burndown Chart, Cycle time, lead time, velocity, etc.
• Wiki- Azure DevOps Wiki is a documentation solution within the Azure DevOps Suite. It can help developers address their documentation needs at various stages of their product development, such as creating specifications, writing meeting reports, or any general information that they would like to share within the team.

I will write more on details of these topics in future articles.