Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>The way that I do it is to have a 'staging' branch that is tracked on your blessed repo. You will want to use the gem 'capistrano-ext' which provides a few extra config options for stages (I think you are already using this considering your call to deploy on staging). <code>capistrano-ext</code> defines stages, which allows you to have a deploy file for each stage, eg 'staging' where you define the branch <code>set :branch, "staging"</code> unique to each stage you are deploying to. You can do your workflow above and add:</p> <pre><code>#after commiting on bug-fix branch git checkout staging # =&gt; tracks staging on origin git merge bug-fix-branch # =&gt; bring new code in git push origin staging # =&gt; capsitrano acts locally, it needs the code to get from origin cap staging deploy # =&gt; wasnt that easy? </code></pre> <p>in an ideal world, you also have a production branch, thus the git branches become agreed upon by the team as</p> <ul> <li>master - edge code where the team shares between devs</li> <li>staging - code to be tested by the client on a staging server (fast-forwards on master merge)</li> <li>production - stable release (fastforwards from staging)</li> </ul> <p>EDIT: the response to the comment was too long so i had to append to the answer.</p> <p>You have several ways to deal with this, I can think of one right away. A fix on prod needs to be reflected in all branches asap so your devs are working on the same base. Assuming prod has a direct common ancestor to staging, and staging to master, a fix on prod should be added to a topic branch based off the HEAD of the prod branch, then merge that change with master and then into staging and finally for deploy into production. The idea is that the only diff is the commits for the bug fix, next time you fast-forward production to the head on staging, you would already have the object that represents the change from the prod bug you fixed, so there is no problem (and since there is good testing for the bug you know it works, after running the suite on each branch). Otherwise you would probably have to cherry-pick a commit from master and apply to prod and staging. Take a look at pro-git.org for more advanced workflows like that.</p>
    singulars
    1. This table or related slice is empty.
    1. POGit Workflow With Capistrano
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USJed Schneider
    1. USJed Schneider
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POGit Workflow With Capistrano
      singulars
      1. PTQuestion
    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. VTAcceptedByOriginator
    1. COYep, we're definitely using capistrano-ext (I couldn't imagine going back). I did have one question with this setup, let's say you've pushed a few changes from master to stage in prep for going to prod when a drop-everything type bug appears on prod. If you create a bug-fix branch from the last tag of production, how do you get that onto stage (and subsequently production) without picking up the other changes?
      singulars
      1. PO
      1. USjerhinesmith
    2. COsee comment appended to answer.
      singulars
      1. PO
      1. USJed Schneider
    3. COI follow that up to the point of "and finally for deploy into production". If you create a branch off of prod HEAD, fix the bug, merge into master, and then staging -- wouldn't staging at that point have your new bug fix along with whatever other features were already pushed to stage? How do you merge from stage to prod so that **only** the bug fix code gets moved up? Thanks again for the help -- I really appreciate it.
      singulars
      1. PO
      1. USjerhinesmith
 

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