Skip to main content

Tulip / Git Integration Overview

Support avatar
Written by Support
Updated over 4 months ago

Connecting a Tulip application connection with Git offers the following advantages:

  • Documentation: Keep a record of all security application configuration changes to ensure they’re easy to trace. This will simplify the process of identifying previous changes during audits and security investigations.

  • Integrate with Ticketing Systems: Connect changes directly to security or compliance tickets for improved tracking and accountability.

  • Collaboration: Improve teamwork and change quality through pull requests (PRs) and peer reviews.

  • Automation: Leverage continuous integration (CI) jobs to automate testing and validation of configuration changes before they are deployed

When connecting to Git, you can choose which one of these features you’d like to use. We recommend users start with the basics of documentation and integration with their ticketing systems, then proceed to more advanced features such as collaboration and automation.

📌 Tulip follows a 'Branch per App Connection' approach, where each app connection is linked to its own Git branch. Each branch keeps a textual record of the app connection latest configuration.

Documentation and Integration with Ticketing Systems

When connected to Git, Tulip keeps the app connection branch synchronized by automatically pushing all configuration changes to it, whether deployed through Tulip or identified during a fetch operation. This creates a complete, auditable history of your security application's configuration, backed by Git.

In addition, when you use ticket IDs in your deployment names, the pushed commits can automatically appear in your ticketing system.

Get started by connecting your Tulip app connection to Git.

Collaboration using Pull Requests

Tulip enhances teamwork and change quality by making deployments dependent on pull requests (PRs) and peer reviews. When enabled, a Pull Request will be automatically created for each deployment made in Tulip. Additionally, you can start working on a change directly in Git, create a PR, and then generate a Tulip deployment from it.

If a PR is attached, deployments will only be allowed if their PRs are mergeable in Git. This allows you to configure branch protection rules in Git, ensuring peer reviews and approvals are required before any changes are deployed to the application connection.

CI/CD and Automation

Attaching pull requests to Tulip deployments enables integration with continuous integration (CI) jobs to automate testing, validate configuration changes before deployment, and run external tools such as static code analysis or compliance checks.

You can enhance your branch protection rules to require these jobs to complete successfully before allowing changes to be deployed to the application connection.

Did this answer your question?