Bitbucket Pipelines glossary
This glossary provides clear definitions of key terms and concepts used in Bitbucket Pipelines. Whether you’re new to continuous integration and deployment (CI/CD) or looking to deepen your understanding, use this resource to get up to speed with the latest terminology and best practices.
Bitbucket Pipelines terminology guide
用語 | 定義 | 例 |
|---|---|---|
Artifact | Files or directories produced by one step and passed to subsequent steps in the pipeline. | “The build step generates an artifact that is used in the deployment step.” |
bitbucket-pipelines.yml | The YAML configuration file stored in your repository root that defines your pipeline workflows, steps, variables, and conditions. | “Update the bitbucket-pipelines.yml file to add a new deployment step.” |
Build | A build is an individual or single pipeline that executes your configured steps to compile, test, package, or otherwise process your code, producing outputs such as artifacts or deployments. | “The build failed because of a missing dependency.” |
キャッシュ | A mechanism to store dependencies or build outputs between pipeline runs to speed up builds. | “Enable caching to reduce your pipeline’s build time.” |
同時実行グループ | A configuration option to limit the number of concurrent builds for a branch or pipeline, ensuring only one build runs at a time per group. | “Set a concurrency group to prevent multiple deployments to production at the same time.” |
条件 | Logic in the YAML file that determines when a step or pipeline should run (for example, only on certain branches). | “Add a condition so this step only runs on the main branch.” |
デプロイメント | The process of releasing built code to an environment (for example, staging, production) as defined in the pipeline. | “After testing, the deployment step pushes the code to production.” |
Deployment variable | Variables scoped to a specific deployment environment, useful for managing environment-specific secrets or configuration. | “Store your production API key as a deployment variable.” |
Dynamic Pipelines | A premium feature allowing runtime modification of pipeline workflows using Atlassian Forge apps for advanced CI/CD logic. | “Use dynamic pipelines to adjust your workflow based on the contents of a pull request.” |
Manual step | A step that requires manual intervention to proceed, often used for approvals before deployment. | “Add a manual step to require approval before deploying to production.” |
パイプライン | An automated process that runs one or more steps to build, test, and deploy code based on triggers (like code commits or pull requests). | “Every push to the repository triggers a pipeline.” |
Pipeline log | The output and logs generated by each step during pipeline execution. | “Check the pipeline log to troubleshoot the failed test.” |
Pipeline permissions | Controls who can view, edit, or run pipelines and access variables. | “Only admins have pipeline permissions to modify deployment variables.” |
パイプラインのステータス | The result of a pipeline run (for example, success, failed, stopped). | “The pipeline status is displayed next to each commit.” |
Repository variable | Variables available to all pipelines in a repository. | “Define a repository variable for your database password.” |
Runner | The execution environment for pipeline steps. Bitbucket provides cloud-hosted runners, and you can also use self-hosted runners. | “Choose a Linux runner for your build steps.” |
Self-hosted runner status ‘DISABLED’ | The runner was temporarily disabled, and steps will not be scheduled on it until it is enabled again. |
|
Self-hosted runner status ‘OFFLINE’ | The runner is not available. It may have been stopped, or there may be network connectivity issues. |
|
Self-hosted runner status ‘ONLINE’ | The runner is live and available for step scheduling. |
|
Self-hosted runner status ‘UNHEALTHY’ | The runner did not complete cleanup and needs manual intervention. |
|
Self-hosted runner status ‘UNREGISTERED’ | The runner was created but was never run. |
|
Secured variable | A variable whose value is encrypted and hidden in logs, used for storing secrets like tokens or passwords. | “Store your API token as a secured variable to keep it safe.” |
Self-hosted runner | A runner that you manage and host yourself, allowing for custom environments or access to private resources. | “Set up a self-hosted runner to access your internal network resources.” |
SSH key | Used for secure access to external systems or repositories during pipeline execution. | “Add an SSH key to your pipeline to clone private repositories.” |
段階 | A logical grouping of steps that can run sequentially or in parallel within a pipeline. | “The test stage runs all unit and integration tests in parallel.” |
ステップ | A single unit of work in a pipeline, typically a set of shell commands executed in a Docker container. | “Add a step to install dependencies before running tests.” |
Third-party secret provider | Integration with external secret management tools to retrieve secrets at runtime. | “Configure a third-party secret provider to fetch credentials securely during builds.” |
トリガー | An event that starts a pipeline, such as a push to a branch, a pull request, or a scheduled cron job. | “A trigger can be set to run the pipeline every night at midnight.” |
変数 | Key-value pairs used to store configuration, secrets, or environment-specific data. Types include repository variables, deployment variables, and secured variables. | “Use a variable to store your API endpoint URL.” |
Workspace variable | Variables available to all repositories within a Bitbucket workspace. | “Set a workspace variable to share credentials across multiple repositories.” |
この内容はお役に立ちましたか?