I think Jenkins CI should help you to achieve what you want.
- You can also manage dependencies between different applications using pre/post build action plugins of Jenkins.
- Build Pipeline plugin should help you to manage the pipeline. The latest plugin allows "retry" which should help you to quickly revert back to the previous builds if you want to.
- I've not used TFS myself, but looks like Jenkins has TFS plugin available.
About the database migrations, versioning DB should be done, in that way you can deploy a migration scripts along with the deployment.
Jenkins + Build Pipeline has been working well for me for a long time. Those were mainly small/medium complex web applications. I've tried it for small iOS and Android apps too.
For a team of 3-4 devs, you're proposing WAY too many branches.
Every branch you create is additional overhead that comes with a cost (time spent merging, keeping track of what's where, etc). You need to make sure that the benefit you get from having a branch outweighs the cost.
Keep in mind that the only real benefit to a branch is code isolation. That means you need a concrete reason to want to have the code isolated.
Having a separate release branch for every sprint is insane. Why do you need the code from one sprint isolated from the code for the next? Why not just have a single stable release branch that gets carried forward with each sprint?
If a change is estimated to take more than a week then it should be done on a branch, with regular merges from the trunk into the branch to stop the two going out of sync.
Almost any non-trivial new feature is going to take at least a week in real time after you account for development, developer testing, daily interruptions and other activities, etc.
Also, what's a "regular merge"? Daily? Weekly? Every merge you do takes time - you need to make sure the target merge branch builds & runs after your changes. On a small team, frequent merging is a lot of overhead.
We have a team of 4 developers working on a 1+ million line codebase and this is how we operate:
- Main branch where all development is done
- One branch per major release (done about once per year)
The one major rule is: don't check in code that doesn't build.
That's it. Simple, easy to understand, gets the isolation we need (at any time we can create a release build for any version).
The upsides to having all development work done on one branch:
- Developers are always in-sync with each other. No painful merges because two developers were off on their own branches for weeks creating incompatible changes.
- Broken builds are found on the same day. We have a nightly build that runs the latest code on main. If someone does check in code that doesn't build for some reason, we will know right away.
- With everyone always working on the same code, in increases the chances of a bug being found sooner rather than later.
- No merge overhead other than targeted fixes to release branches. On a small team, this is the big one.
Best Answer
I'd first research some possibilities. For instance, Hudson is a rather popular continuous integration server and is extremely flexible. You could e-mail your dev team with something like this:
This approach has the following benefits:
In my mock scenario,
Davewas selected because he has the least on his plate and would probably have no problem setting up a new server. Depending on the work load,Davemight just have to be you. That's so subjective that I simply mention it. You can't always saynot my job to do thatespecially if you are the only one who has time to do it. If everyone is already pulling over time, their perception of your willingness to help becomes more important. Gauging that is a skill you develop over time.In any event, you'll either have a CIS server by Friday, or details on why that just isn't possible without an extra set of hands.