Core concepts

Branching

Software developers typically use version control systems to coordinate work in a codebase. This enables multiple engineers to contribute to the same code safely.

In the Palantir platform, you can think about data and change management the way software developers think about code: you need a way to allow many people to make changes and interact with the same data without interfering with someone else's work. Foundry Branching takes the best practices from software development and applies them to the Palantir platform, harnessing a common feature of version control systems called branching.

At a high level, branching allows you to take a fork in the road and work on components of your end to end workflow in your own branch. Then, once you are satisfied with your changes, you can deploy your changes out of your branch back to the main road.

Branching workflow

The diagram below shows you can use a branching workflow to make changes to data pipeline code, Ontology, and Workshop applications in the Palantir platform.

To follow a branching workflow:

1. Create a branch: In Foundry, the main branch refers to the primary assets in production that are used by application builders, such as data pipelines, Ontology, and Workshop applications. When you want to work on your own changes, you create your own branch, which creates an environment for you to experiment and test out ideas without worrying about affecting the main branch.
2. Create changes: Within your branch, you can make changes to data transformations, Ontology, and Workshop applications. Your changes are tracked so that there is a clear history of all the updates you have made on your branch.
3. Create a proposal: Once you are finished working in isolation, you will want to deploy your changes back to the main branch. To start this process, you create a proposal. A proposal signals to your team that you have made changes you would like them to review and validate for the main branch. A proposal contains metadata such as reviews, name, and descriptions of the changes being deployed into the main branch. Proposals serve as a mechanism for reviewing and approving changes made in a separate branch before they are integrated into the main branch. Creating a proposal through the Foundry Branching interface provides a unified experience to create proposals for all the changed assets.
4. Review proposal: After you create a proposal, your team will have the chance to review your changes. Every organization will have a different process or team for reviewing proposals.

Branch statuses

• Active: Branches that are in progress or approved.
• Deployed: Branches that have been deployed to main branch.
• Inactive: Branches that have not seen activity after the configured number of days are marked as inactive. See Retention Policy for additional details.
• Closed: Branches that have been closed, and were not deployed. Branches that are inactive for the configured number of days will automatically get closed, and their resources get deleted if not deployed to main, to reduce the cost of branches. Branches with active open proposals will not be automatically closed. See Retention Policy for additional details.
  • Closed branches cannot be reopened.

Proposal

A proposal is analogous to a pull request in a version control system, specifically tailored for Foundry branches. A proposal can be created for a branch and contains metadata such as reviews, name, the tracked changes, and descriptions of the changes being deployed into the main branch. Proposals serve as a mechanism for reviewing and approving changes made in a separate branch before they are integrated into the main branch. A single proposal can contain a single or multiple changes.

Proposal statuses

• Active: Proposals that are in progress or approved.
• Deployed: Proposals that have been deployed to main branch.
• Closed: Proposals that have been closed, and were not deployed.