Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>At my previous job, we used a similar approach to what @Alexis mentioned, with one main difference. Keep in mind we were working on a new version of some pretty major legacy software (our codebase was several million lines of code, between Java, flex and COBOL) and had a customer partner beta testing for us. Releases were bi-/weekly, including to the customer (though they would typically be one release behind latest, as that one would go through QA first), and in that week we had to do a 'cut', test, basic QA by the client of our code, which was another developer in the company, and then release to real QA.</p> <p>Essentially, master was our dev branch. If a dev item was to take more than a day or two, it was completed on a feature branch and then merged into dev when ready. There was another 'future' dev branch that was reserved for fairly serious new feature work (anything that changed the program in a significant way), or major refactoring. At some point this would become main 'dev' when we decided that we had time to properly test and iron out bugs, or that it was time to introduce the new features and deal with the inevitable pain :)</p> <p>When it was time for a release, a new branch was created called 'release_x', then all fixes that came from QA were implemented there and merged 'up'. By that I mean that we could have two or three versions in play at any one time, so the customer would obviously have the oldest which we might do a fix for if they found a showstopper. This would be done on a hotfix branch coming off the relevant release, which at some point would be merged into that release and deleted (so you could easily see outstanding hotfixes in a branch list) and another build done and sent to the customer. The 'hotfix' branches existed so that we could pick and choose what went into a particular build, which functioned for the customer release as well as the developer release, to avoid potentially risky fixes for small issues upsetting the release of a fix for a showstopper.</p> <p>That would then be merged up to the release that the QA guys had, then that would be merged to the release the other developers were using (always the latest release due to their reliance on our plugins and j2ee infrastructure to do their work), then back into dev, just to keep everything on the level.</p> <p>All of the releases currently in play had their own automated build loop in Jenkins, as well as the dev branch, with some automated functional tests running on the more important ones (dev and QA mainly). Each build added a tag to the report on the commit that was used as HEAD, and the build number was available from the program so that we could see <em>exactly</em> which version the bug reporter was using.</p> <p>So essentially, two dev branches, one of them for major work to be released later as a new major version. Release branches for each release, with hotfix branches coming off those. Finding the latest release was an easy matter, look for the release branch with the biggest number.</p> <p>The only downside was that if you did many fixes at a release several versions back, then the merging graphs were... interesting to follow :)</p>
    singulars
    1. This table or related slice is empty.
    1. POGit Workflow and Release Branches: Many, One, or None?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USMattJenko
    1. USMattJenko
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. This table or related slice is empty.
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload