Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>If you have a small-medium team then avoid extra branches when you don't truly need full branch isolation... especially if your dev team's culture is averse to branching and merging properly. Perhaps in exchange for fewer branches to maintain make sure merging practices are followed <em>religiously</em> by all developers who are allowed to do merges. Shelvesets (in TFS) and short-lived feature branches are good techniques to minimize merge overhead and related risks.</p> <h3>DETAILS</h3> <p>Here's a pattern I've found to balance productivity with version control safety (for team of ~25 devs and ~3 testers):</p> <ol> <li><p><strong>Work in same branch:</strong> Developers working on loosly coupled or unrelated code can work directly in the same Dev (or "Integration") branch relatively safely. Bugfixes and non-breaking changes nicely fit here (lower risk of major regressions impacting other devs). Continuous Integration builds and gated builds are two best practices that mitigate risk of many devs working in the same branch. <strong>Toggle Note:</strong> Feature toggles can be used to further avoid need to branch, but make sure overhead to test/maintain the toggle behavior isn't riskier than using a branch.</p></li> <li><p><strong>Shelvesets:</strong> Use your version control system's feature to save pending changes in developer-specific proto-branches. Developers checking in to TFS (Team Foundation Server) can use shelvesets instead of personal branches (or many micro-feature/task branches) if they are the only one who needs to develop and test the feature before checking in to the integration/dev branch. I believe other version control systems have similar constructs <strong>ANTIPATTERN:</strong> Local workspace(s) automatically provide temporary isolation for each developer... but developers need to check in their changes frequently/daily somewhere in source control to prevent risk of losing days+ of local-only work.)</p></li> <li><p><strong>Short-lived branches:</strong> When you do need a branch for isolation (such as for a breaking feature that multiple developers need to work on) then creating short-lived feature branches is one good way to go. I recommend a branch naming convention that keeps branch use well defined and unique over time.</p></li> </ol> <p>The primary advantage of the above workflow is that it minimizes the merge tax (time spent Integrating forward/reverse (merging down/up)) instead of developing features that directly improve customer happiness.</p> <p><strong>Example Scenario:</strong> The new "Cool" feature will break existing functionality and builds until completed. It also requires 2+ devs to collaborate on same codebase (eliminating option to use Shelveset). Dev owner for "Cool" Creates branch named <strong>Cool1</strong>, then develop &amp; integration test the first version of feature. Dev owner is responsible for merging parent changes daily (weekly at absolute most). Confirm ready to merge (Parent merged do child (FI), all UT and core Acceptance Tests run and still pass). Merge to parent (RI), then confirm works in parent branch (all UT and core Acceptance Tests pass), then delete the <strong>Cool1</strong> feature branch (cleanup).<br> Test the Cool feature more thoroughly after merged to dev/integration branch. (Test resources are limited so avoid full test environment for each branch.) Bugfixes and tactical enhancements/refactoring for Cool would are done directly in the Dev branch (using shelvesets when assigned dev needs many days to localy dev/test before checkin). If major (multi-developer) rework of Cool is needed later then create a new <strong>Cool2</strong> branch.</p> <p><strong>TFS2010 move/rename Note:</strong> TFS 2010 move and rename behavior changed (from TFS 2008) to make moves and Renames = "branch to new name/location, then mark original item as deleted". This means you should just delete the inactive feature branches if you don't want to see them in source control \Dev\ instead of moving the branch to a different folder. This also means developers that enable viewing deleted folders will always see these deleted (or moved or renamed) short-lived branches as "ghosts" which can get cluttered. (That's how you can view history or undelete a deleted item.)</p>
    singulars
    1. This table or related slice is empty.
    1. POBranch by feature - Advantages/disadvantages?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USZephan Schroeder
    1. USZephan Schroeder
    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
    3. 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