As someone who works with databases and often collaborates with software development teams, I've noticed a rise in the popularity of DevOps for Databases, which has raised some interesting questions on the topic of database and application source control.
One of the most pressing questions is how to handle SQL Database projects in relation to app code projects in terms of source control. Should they be in the same repository and solution? Separate repositories? Separate solutions?
In this article, I'll be focusing on Git as the source control type and exploring the benefits and drawbacks of different approaches.
Permissions
When it comes to permissions, Git platforms typically define a person's access at the repository level, so it makes sense to have separate repositories for each project when different teams with different types of access are involved.
However, if there is only one development team or if the same team is responsible for multiple projects, then splitting projects into different repositories wouldn't make much of a difference in terms of permissions.
Branching and Versioning
Another important factor to consider is branching and versioning. GitFlow is a commonly used branching policy, where the "master" or "main" branch represents what is currently live in production, the "dev" or "develop" branch represents the next version in development, and "feature branches" represent individual developments that are merged back into "develop" when completed.
When it comes to merging from "dev" to "main," it's important to ensure that all the changes in the branch are fully aligned in terms of versioning and readiness for production. Otherwise, we risk accidentally deploying a partial version of something.
CI/CD Pipelines
Lastly, when configuring a CI/CD pipeline, it's crucial to consider which branch or set of branches the pipeline should be automatically triggered by. Typically, pipelines are activated when there's a push or approved pull request into a certain branch, but they can also be configured to listen for specific tags. If multiple projects should trigger the same CI/CD pipeline(s), then it should be okay to save them in the same repository. Otherwise, you'll have unnecessary pipeline executions, and potential harm would be done to your environment due to partial deployments.
Conclusion
In conclusion, the decision to keep SQL Database projects and app code projects in the same repository or separate repositories depends on various factors, such as permissions, branching and versioning, and CI/CD pipeline configurations.
To learn more about these factors and make an informed decision, I encourage you to read the full blog post on my official website.
The discussion on whether to keep database and application projects in the same source control repository is highly relevant for teams looking to streamline their development processes. Maintaining clear separation can enhance collaboration and reduce errors. For organizations aiming for efficiency, leveraging IMR Digital tools can provide valuable insights into best practices for source control management. It's crucial to adopt strategies that facilitate smooth integration while minimizing risks.