Setting Up the GitHub Connection
To connect GitHub to Azure Pipelines, you need to create a service connection that acts as a secure bridge between the two systems. Azure Pipelines supports two authentication methods: personal access tokens (PAT), which are generated in GitHub and pasted into Azure, and OAuth apps, which redirect you to GitHub for authorization. The choice between them depends on your security needs—PATs work well for individual users or quick setups, while OAuth is better for organizations that want to manage permissions through GitHub. Once configured, the service connection stores your credentials securely and allows Azure Pipelines to read code, trigger builds, and report status back to GitHub.
How Webhooks Trigger Pipelines
When developers push code or create pull requests, webhooks notify Azure Pipelines that work needs to happen. A webhook is a configuration in GitHub that sends an HTTP POST message to a specific URL whenever an event occurs. The payload contains details about what changed, who changed it, and which repository is involved. Azure Pipelines receives this message, parses it, and starts the appropriate pipeline. You can choose which events trigger pipelines—common options include every push to any branch, pushes to specific branches only, or pull request activities.
Branch and Event Triggers
Pipelines can be configured to run only when certain conditions are met, which helps teams avoid unnecessary builds and focus on important changes. Branch triggers let you specify which branches should start a pipeline; for example, you might want builds to run only on the main branch or on any branch that starts with "release/". Event triggers determine what kind of GitHub activity causes the pipeline to run, such as code pushes, pull requests, or tag creations. When both branch and event filters match, Azure Pipelines creates a new build run automatically.
Security and Access Control
Keeping the integration secure requires managing permission scopes and protecting important branches from unintended changes. The service connection should be granted the minimum permissions needed—typically read access to code and write access to commit statuses, but not full administrative rights. Branch protection policies add another layer of safety by requiring pull request reviews, status check passes, or approval from specific people before changes can be merged. Pipeline status checks ensure that builds must succeed before code can be merged, which prevents broken code from reaching protected branches. Together, these controls create a safe workflow where automated pipelines validate changes before they become permanent.