How do you establish source control and a release process?
Created with AI.
Source control provides a history and the ability to roll back. This guide describes a setup that is realistic for a small team.
- 7 steps
- Total time: 4 h
- Preparation: 2 h
- Result: Configuration under version control with an agreed release process
Required tools
- A Git repository — Azure DevOps or GitHub.
- Tool for extracting solutions — Power Platform CLI or equivalent.
Get started
1.Extract the solution into the file structure
An exported solution is one large file. When unpacked, it becomes many small files, one per component. The unpacked format is what makes sense in Git—the large file does not show any differences.
2.Add an initial version as a starting point
Assess the current state before making any changes. This gives you a baseline for comparison from day one.
3.Agree on who checks in and when
After every meaningful change, not once a month. A history with large gaps is almost as unhelpful as no history at all.
Establish the release routine
4.Distinguish between the development branch and the release branch
It must be possible to precisely identify what is in production. A separate branch or version tag for each release allows you to recreate that exact state.
5.Automate builds and deployment once the routine is established
Start manually until you know what the process looks like. Then automate the repetitive parts. Automating a routine that no one has tried only makes mistakes happen faster.
6.Tag each production release
The version number associated with what is actually in production. This is what makes a rollback possible rather than merely theoretical.
7.Write a short release log
What was changed, by whom, and why. Three lines per release are enough, and this is what answers the question of what changed when the problem occurred.
Discussion
Ask a question or share what helped you.
