Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,560,525
Community Members
 
Community Events
185
Community Groups

Git workflow with SQL Server databases (SSDT)

Our simplified structure is:
                      / developer1_database
SQL Server -- developer2_database
                      \ main_database <-- report server

developerX_database - database that is used only by single developer, he is free to deploy anything and anytime there.
main_database - currently the database that is automatically updated with every push to develop branch. REPORTS that are under testing are pointed to that database.

This is more or less the vision how do we see the process is supposed to be look like:

* Dev creates feature branch
* Dev push changes to feature branch
* Dev create pull request to develop branch
* Other devs approve pull requests
* Release manager merge feature to develop branch
* Relase manager initiate build that would test the changes and output deploy script
* Release manager reviews output script and run it on prod
* Release manager merges changes to master branch

Now we have problems/questions:
1) We would like to have clean pull requests only, the best way would be that before we merge it to develop it is supposed to be buildable and all tests passed. How and where to test it?
2) We would like to allow the business to test report before it merged into the develop database. This process can take time so the "feature" version of the database state must exist somewhere. Where? If we use "developer" database for that then he will not be able to switch to another feature as he will just nuke all his changes from previous feature when he would deploy the new one.

 

0 answers

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events