Concepts
To better understand Build, familiarize yourself with these concepts.
Projects
Projects in Build represent the components and applications that your company develops. Each project has its own pipeline for release or distribution. Projects often correspond to how development is organized in your source control management system. Projects might also be composites of other projects that use a dependency management system. If components are developed independently and then composed into applications, the components themselves can become projects that support other projects that represent applications or products. Projects are created with project templates.
Build processes
A build process is a configuration that you run to conduct a build on some source material.
- Everything that happens during builds and everything that is required by them.
- Where to get source code and dependencies.
- What tools are required to build.
- What tests need to run.
Source configurations
A source configuration identifies the source material for a build. They can define the branch or label to pull source material from, or use other criteria. Source configurations are attached to build processes. A build process can have multiple source configurations assigned to it if it pulls source code from multiple locations. Source code locations can be in multiple repositories and from any type of source control system. Source configurations are created with source configuration templates.
Source repositories
A source repository configuration supplies the information that is required to connect to an external source repository. Because source repository configurations do not define the details of any particular source, they are highly reusable.
Dependencies
Dependencies are configured to provide artifacts and build triggers between projects and third-party artifacts, such as open source libraries. When you create a dependency for a build process, you identify the artifacts that your build requires to run or build. Dependencies are highly configurable; you can specify criteria for version, or status, or other characteristics. Dependencies can trigger builds, which can work bi-directionally by pushing or pulling. Pull dependencies retrieve material from other sources, and push dependencies send material to other targets. If you have a common component project, you might trigger builds when the common project changes.
Templates
Templates are reusable configurations that define projects and processes. Each template encapsulates a type of project, such as a source configuration, workflow, job, or process. You can create templates properties and define their values at design time or run time. For instance, a template might always call a particular type of build script, but the name or location of the script might vary by project. Templates provide a high level of reuse because you decide the number of properties and when their values are defined.
Processes
A process defines the jobs and steps that go into a build. Processes are created with process definition templates, and like all templates, they are reusable. A number of built-in steps are available, but most of steps come from plug-ins. Steps are collected into jobs and jobs are composed into processes. When you place a job in a process, you specify several options, including the agent pool, the working directory, and others. With processes, you can run jobs in parallel and then join them later. Jobs can also be iterated to run a number of times. Each job run can have its own properties, which are useful for multi-platform, parallel builds.
Build lives
A build life is record of a build. It records the inputs, the build activities, the produced artifacts, and activities that are done after the build. A build life tracks the source, the dependencies, the computer that is used, and the deployment or release of the produced artifacts. All completed steps and their output are recorded. Tests can be recorded, along with defects, features, and stories. Each build has a unique build life.
Secondary processes
A build process produces a new build; a secondary process runs on a build life. Secondary processes can be run only on an existing build life with at least one completed build process. Typically, secondary processes are used for tests or analytic tools. If one of your test suites takes an unusually long time, you might want to schedule it to run nightly in a secondary process.