Merge for Oracle code

Uhteen

Hi,

We have a scenario wherein we use multiple environments(lets say 5) for code development and then use one of the environment for each release.

eg: env1, env2, env3, env4, env5 are used for development which have the same set of config and apps installed.

env1 is used for dev and testing of code for Jan release
env2 is used for dev and testing of code for feb release

Now if we want to retrofit the recently released DB oracle code from env1 across other env we are blocked. We cannot simply overlap the code that is there in env2 as the change for feb release is already done on it(yes, without the recent code from env1). this is the problem. is there any merge option that any of your tools provide? and we are also looking at devops for DB code along with .net code. Is that possible?

AlexYates

This is all a question about source control branching. You should manage all the source code for all the different branches in source control.

There are of course plenty of different branching strategies with different pros and cons and plenty of people who feel strongly about one way or the other being the best and I don't fancy getting drawn into one of those debates. Ideally, however, your branching strategy should match your reality.

I wrote a bit more detail on that point here:
http://workingwithdevs.com/branching-reality/

Of course, that approach will have limitations based on the tooling you choose. Git, for example, is far better able to cope with complicated branching strategies than TFSVC or SVN, but its also a bit of a learning curve and complicated branching strategies can get pretty confusing pretty quickly. It's not a perfect science despite what you may read.

However, once you have fixed the source control branching issue you should be able to deploy your code based on the source code, rather than trying to sift through a bunch of work in progress and copy specific changes from one database to another.

I wrote about one POC creating an Oracle database deployment pipeline based on source control here:
http://workingwithdevs.com/continuous-delivery-oracle-databases-bamboo-redgate-1/

Uhteen

Thanks Alex, We are currently using TFS, we really don't have an option of moving to git for better branching, we will have to play with what we have. So any pointers there would help us greatly.

AlexYates

Worth clarifying if it is possible to move to a Git repo in TFS? (TFS supports both TFSVC and Git repos now.) If TFSVC then you will need to limit the number of branches quite tightly for plain technical/complexity/tooling reasons.

So the advice here is to simplify your branching strategy but the necessary consequence is that you should simplify your reality to match. If your reality and your branches don't match the slipper won't fit, people will break the rules and it will be enormously painful.

So how do you do that? The simple old truths:

- Use source control and ensure it is the sole source of truth.
- Ensure all teams (Dev/DBA/test etc) are aligned.
- Limit work in progress.
- Release small batches regularly.
- Minimise the amount of concurrent epics that different teams are working on against the same codebase.

Note these are mostly human/project management changes, not technical ones. Unfortunately that will probably mean you need to push back on project managers etc, which is often difficult.

AlexYates

Also, Schema Compare is your friend. And the more progress you can make on the human stuff above, the easier that merge will be.