Learning Path review questions: LP02

Learning Path review questions

01. What are some advantages of Azure Pipelines?

Azure Pipelines provides a variety of benefits for DevOps teams.

Some of the key advantages include:

1. Cross-Platform Support: Azure Pipelines supports building and deploying code for different platforms (Windows, Linux, macOS), making it versatile for a wide range of applications.

2. Integration with Version Control: Azure Pipelines integrates with multiple source control systems, including GitHub, GitLab, and Azure Repos, allowing for seamless automation from code commit to deployment.

3. Continuous Integration and Delivery (CI/CD): It provides an end-to-end solution for continuous integration (CI) and continuous deployment (CD), automating testing and deployment pipelines.

4. Scalability: Azure Pipelines is highly scalable and can handle everything from small projects to large-scale enterprise applications with complex workflows.

5. Cloud-Native and On-Premises Support: Azure Pipelines can run both on Azure and on-premises (self-hosted agents), allowing flexibility in where the build and deployment processes occur.

6. Integration with Azure DevOps Services: Azure Pipelines integrates well with other Azure DevOps services like Boards, Repos, Test Plans, and Artifacts, making it a comprehensive solution for managing the software development lifecycle.

7. Extensibility: Azure Pipelines supports a wide range of extensions from the Azure Marketplace, which allows teams to customize the pipeline to meet their needs.

02. What is a pipeline, and why is it used?

A pipeline in Azure Pipelines refers to an automated workflow that helps in building, testing, and deploying applications. Pipelines are used to automate tasks in software development, from code commit to production deployment.

Why is it used?:

1. Automation: Pipelines automate repetitive tasks, reducing human error and increasing efficiency.

2. Consistency: Pipelines ensure that the same steps are followed each time, leading to consistent builds, tests, and deployments.

3. Continuous Integration/Continuous Delivery (CI/CD): Pipelines are the core of CI/CD practices, enabling developers to integrate code frequently and deploy to production in a repeatable, reliable manner.

4. Version Control Integration: Pipelines are tightly integrated with version control systems to trigger builds and deployments automatically on code changes.

5. Quality Assurance: Automated tests and checks within pipelines help to ensure quality before code moves to the next stage.

03. What is the line continuation character in Dockerfiles?

The line continuation character in Dockerfiles is the backslash (\). It allows you to split a long command into multiple lines for readability, without affecting the execution of the Dockerfile.

Example:

xxxxxxxxxx
3
1
RUN apt-get update && \
2
    apt-get install -y python3 && \
3
    apt-get install -y python3-pip

In this example, the RUN command is split across multiple lines for better readability, but it will execute as a single command in the Docker image.

04. What are the two types of agents and how are they different?

There are two main types of agents in Azure Pipelines:

Microsoft-Hosted Agents:

1. Managed by Azure: These agents are provided and maintained by Azure.

2. Ready to use: Pre-installed with common tools (like .NET, Node.js, Java, etc.), so you don’t need to configure or maintain them yourself.

3. Ephemeral: They are created for each pipeline run and are discarded once the job is completed. You don't have to worry about maintaining the environment.

Self-Hosted Agents:

1. Managed by the User: These agents are set up and managed by you. You install them on your own infrastructure or on virtual machines.

2. Persistent: They persist between pipeline runs, which means you can configure them with specific software, tools, and configurations required for your builds.

3. Customization: You have more control over the environment, allowing you to use custom tools or software versions that aren’t available on Microsoft-hosted agents.

Differences:

1. Microsoft-hosted agents are managed by Azure and are automatically updated, but they can be slower since they are ephemeral and may require downloading dependencies for each build.

2. Self-hosted agents give you more control and can potentially be faster (since dependencies can be pre-installed), but require maintenance and management.

05. What is an agent pool, and why would you use it?

An agent pool is a collection of agents (either Microsoft-hosted or self-hosted) that Azure Pipelines can use to run jobs. It provides a way to group and manage multiple agents, either for specific projects or for specific workloads.

Why use an agent pool?

1. Organizational purposes: You can group agents that belong to different environments or departments (e.g., one pool for development, another for production).

2. Resource Management: It enables you to manage the resources more effectively by defining pools that are optimized for certain types of jobs or workloads.

3. Load Balancing: If you have multiple agents, jobs can be automatically distributed across them based on availability.

4. Custom Environment: If you need certain agents with specific configurations (e.g., special build tools), you can assign them to a dedicated agent pool.

06. What are two ways to configure your Azure Pipelines?

There are two primary ways to configure Azure Pipelines:

YAML Pipelines:

A declarative method where you define your pipeline in a .yml file (called azure-pipelines.yml).

This approach is version-controlled, meaning the pipeline configuration is stored alongside your source code, making it easy to track changes.

YAML allows for flexibility and reuse of pipeline templates.

Example:

xxxxxxxxxx
15
1
trigger:
2
  branches:
3
    include:
4
      - main
5
jobs:
6
  - job: Build
7
    steps:
8
      - task: UseDotNet@2
9
        inputs:
10
          packageType: 'sdk'
11
          version: '3.x'
12
      - task: DotNetCoreCLI@2
13
        inputs:
14
          command: 'restore'
15
          projects: '**/.csproj'

Classic Pipelines:

A visual method where you configure the pipeline using the Azure DevOps UI.

This method is more user-friendly, allowing you to create, edit, and manage pipelines without needing to write code.

Classic pipelines are often more suitable for beginners or simple use cases where you don’t need the full flexibility of YAML.

07. Name the four pillars of continuous integration.

The four pillars of Continuous Integration (CI) are:

1. Version Control: All code is stored in a shared version control system (e.g., Git), and developers commit changes frequently.

2. Automated Build: The code is built automatically upon every change, ensuring that it integrates correctly and that there are no issues with dependencies.

3. Automated Testing: Tests (unit, integration, and other automated tests) are run automatically to verify the correctness of the code.

4. Frequent Integration: Developers frequently commit their changes (at least daily) to the shared repository to avoid integration conflicts.

These four pillars ensure that code is always in a deployable state and that issues are caught early in the development process.

08. You want to take your build server offline to make a configuration change. You want it to complete any build that it is currently processing, but you want to queue any new build requests. What should you do?

To achieve this, you can disable the agent in Azure Pipelines:

1. Go to Agent Pools in Azure DevOps.

2. Select the agent you want to take offline.

3. Click on Disable to stop new builds from being assigned to that agent.

Any builds that are already in progress will continue to run to completion.

Disabling the agent ensures no new jobs will be queued while maintaining the execution of ongoing jobs.

09. You want to set a maximum time that builds should not run for more than 5 minutes. What configuration change should you make?

You can set a build timeout in the pipeline configuration:

For YAML pipelines, you can define the timeoutInMinutes property in the pipeline YAML file.

Example:

xxxxxxxxxx
5
1
jobs:
2
  - job: Build
3
    timeoutInMinutes: 5
4
    steps:
5
      - task: <task name>

For Classic pipelines, you can set the timeout in the pipeline UI by navigating to the pipeline settings and specifying the maximum build time.

10. True or False: Self-hosted runners should be used with public repos.

False:

Self-hosted runners are typically not recommended for use with public repositories because they may expose your infrastructure to potential security risks. Public repositories can be accessed by anyone, including malicious users, which could pose a risk if you use self-hosted runners that contain sensitive information or configurations.

Public repositories are better suited to Microsoft-hosted agents that are more secure and isolated.

11. Database passwords that are needed in a CI pipeline should be stored where?

Database passwords and other sensitive information should be stored in Azure Key Vault or a similar secrets management system. Azure Key Vault provides secure storage for secrets, and you can integrate it with Azure Pipelines to securely access secrets without hardcoding them in your code or pipeline configuration.

You can reference secrets from Azure Key Vault in your pipeline using the Azure Key Vault task.

12. The metadata for an action is held in which file?

In GitHub Actions, the metadata for an action is typically stored in the action.yml (or action.yaml) file. This file contains the action's name, description, inputs, outputs, and other relevant information.

Example of action.yml:

xxxxxxxxxx
13
1
name: 'My Action'
2
description: 'An example GitHub Action'
3
inputs:
4
  exampleInput:
5
    description: 'An example input'
6
    required: true
7
    default: 'default-value'
8
outputs:
9
  exampleOutput:
10
    description: 'An example output'
11
runs:
12
  using: 'node12'
13
  main: 'dist/index.js'

13. How can the status of a workflow be shown in a repository?

The status of a workflow in a repository can be displayed through:

1. GitHub Status Checks: In GitHub, each commit will show the status of the associated workflow (e.g., whether the build passed or failed) directly in the pull request or commit view.

2. Badges: GitHub Actions and other CI tools often provide badges that show the status of a build (success, failure, etc.) for the most recent build of a branch or commit. These badges can be added to the repository's README.md to give visibility to the workflow status.

Example of a build status badge:

xxxxxxxxxx
1
1
![Build Status](https://img.shields.io/github/workflow/status/{owner}/{repo}/{workflow})