Az400 exam readiness videos

Traceability

Git

Fork workflow

The following is a step-by-step example of this workflow:

• A developer ‘forks’ an ‘official’ server-side repository. It creates their server-side copy.
• The new server-side copy is cloned to their local system.
• A Git remote path for the ‘official’ repository is added to the local clone.
• A new local feature branch is created.
• The developer makes changes to the new branch.
• New commits are created for the changes.
• The branch gets pushed to the developer’s server-side copy.
• The developer opens a pull request from the new branch to the ‘official’ repository.
• The pull request gets approved for merge and is merged into the original server-side repository.

To integrate the feature into the official codebase:

• The maintainer pulls the contributor’s changes into their local repository.
• Checks to make sure it doesn’t break the project.
• Merges it into their local main branch.
• Pushes the main branch to the official repository on the server.

It’s essential to note that “forked” repositories and “forking” aren’t special operations.

Forked repositories are created using the standard git clone command. Forked repositories are generally “server-side clones” managed and hosted by a Git service provider such as Azure Repos.

There’s no unique Git command to create forked repositories.

A clone operation is essentially a copy of a repository and its history.

Git Hooks

Can run code before/after Git events.

Hooks can be any executable code. They must be stored in the .git/hooks dir

Also, they must be named to match the related events (Git 2.x):

applypatch-msg pre-applypatch post-applypatch pre-commit prepare-commit-msg commit-msg post-commit pre-rebase post-checkout post-merge pre-receive update post-receive post-update pre-auto-gc post-rewrite pre-push

Azure Pipelines

The agent communicates with Azure Pipelines to determine which job it needs to run and report the logs and job status.

The agent always starts this communication. All the messages from the agent to Azure Pipelines over HTTPS, depending on how you configure the agent.

This pull model allows the agent to be configured in different topologies, as shown below.

CI with Github

environmental variables

Github provides number of built-in env variables that start with GITHUB_ prefix

Sharing artifacts between jobs

When using GitHub Actions for CI/CD, you’ll often need to pass artifacts created by one job to another.

Most common way is using either upload-artifact or download-artifact:

Upload specific file:

- uses: actions/upload-artifact
  with:
    name: harness-build-log
    path: bin/output/logs/harness.log

Upload entire folder:

- uses: actions/upload-artifact
  with:
    name: harness-build-logs
    path: bin/output/logs/

# or use wildcards
- uses: actions/upload-artifact
  with:
    name: harness-build-logs
    path: bin/output/logs/harness[ab]?/*
# or multiple paths
- uses: actions/upload-artifact
  with:
    name: harness-build-logs
    path: |
        bin/output/logs/harness.log
        bin/output/logs/harnessbuild.txt

Download-artifact

- uses: actions/download-artifact
  with:
    name: harness-build-log

Workflow badges

Badges can be used to show the status of a workflow within a repository.

They show if a workflow is currently passing or failing. While they can appear in several locations, they typically get added to the README.md file for the repository.

Badges are added by using URLs. The URLs are formed as follows:

https://github.com///actions/workflows//badge.svg

Where:

AAAAA is the account name. RRRRR is the repository name. WWWWW is the workflow name. Example: https://github.com/AAAAA/RRRRR/actions/workflows/WWWWW/badge.svg

Secrets

Secrets aren’t passed automatically to the runners when workflows are executed.

Instead, when you include an action that requires access to a secret, you use the secrets context to provide it.

steps:

  - name: Test Database Connectivity
    with:
      db_username: $
      db_password: $

Release

We start with defining a release process or release pipeline. The release pipeline contains all the steps you walk through when you move your artifact from one of the artifact sources discussed earlier through the stages or environments.

The stage can be a development stage, a test stage, a production stage, or a stage where a specific user can access the application.

Part of your pipeline is the people who approve the release or the deployment to a specific stage. Also, triggers or schedules on which the releases execute, and the release gates, the automatic approvals of the process.

The release itself is something different. The release is an instance of the release pipeline. You can compare it with object instantiation.

In Object Orientation, a class contains the blueprint or definition of an object. But the object itself is an instance of that blueprint.