Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I run a Rails website for <a href="http://www.madisonbrass.com/" rel="noreferrer" title="Madison Brass Band">a brass band in Wisconsin</a> in a very similar setup to what you're describing, though it currently operates out of hostingrails.com. I host my code <a href="http://github.com/mbb/mbb-website" rel="noreferrer" title="Code on Github">on github</a>, though there's no reason you couldn't host it privately. My flow has evolved over the last year and a half, so take from this only what you need in the short term.</p> <p>At the center of my flow, I have set up <a href="http://github.com/mbb/mbb-website/blob/70f66b1058f6e62c041b6bd7b94399e9da31ff0c/config/deploy.rb" rel="noreferrer" title="Script code, at time of writing.">a semi-elaborate Capistrano script</a> to handle the deployment, including <a href="http://github.com/mbb/mbb-website/blob/70f66b1058f6e62c041b6bd7b94399e9da31ff0c/config/deploy/staging.rb" rel="noreferrer" title="Code, at time of writing.">a separate staging environment</a> that makes a whole copy of the production database for testing. This took a while (hours, not days) to build, but it has been <em>so</em> worth it.</p> <p>My workflow keeps <a href="http://github.com/mbb/mbb-website/network" rel="noreferrer" title="Illustration of Current Development">at least 2 branches</a>:</p> <ul> <li><strong><code>current_release</code>:</strong> Live production code. Emergency bugfixes are made here.</li> <li><strong><code>master</code>:</strong> Finished features ready for release. These features wait here to be tested live. Emergency bugfixes are merged in from <code>current_release</code>.</li> <li><strong><code>&lt;feature_name&gt;</code>:</strong> Features under development. I try not to have more than 3 of these outstanding at any given time. Emergency bugfixes are merged in, and <code>master</code> is frequently merged in to keep the feature current.</li> </ul> <p>Having this setup allows me to work on several things concurrently. Week-to-week (as this is nowhere near a full-time occupation), I do the following:</p> <ol> <li><p>I edit in feature branches. I switch back and forth, get bored, get excited, whatever. Sometimes I merge two features that grow together.</p> <p><code> [edit]<br> $ git commit<br> $ git push github [feature] </code></p></li> <li><p>Finished features ready for iminent deployment are merged one-at-a-time to the <code>master</code> branch.</p> <p><code> $ git checkout master<br> $ git merge [feature]<br> [fix immediate problems or inconsistencies]<br> $ git commit<br> $ git push github master<br> $ git branch -d [feature] </code></p></li> <li><p>I stage the website to a private URL (happens to be stage.madisonbrass.com). The <em>staging</em> environment always pulls from the <code>master</code> branch.</p> <p><code> $ cap staging deploy # <code>master</code> is now live at stage.madisonbrass.com </code></p></li> <li><p>Bam, while I'm testing, I find an emergency bug on the public website. Fortunately, I have <code>current_release</code> working separately, and thus can separately fix and deploy it.</p> <p><code> $ git checkout current_release<br> [fix bug]<br> $ git commit<br> $ git push github current_release<br> $ cap production deploy </code></p></li> <li><p>I return to the <code>master</code> branch, and start by merging the emergency fix.</p> <p><code> $ git checkout master<br> $ git merge current_release </code></p></li> <li><p>I continue testing <code>master</code>. Hopefully no new issues appear, but if they do I fix them in master, I merge these changes into <code>current_release</code> and do another production deployment.</p> <p><code> $ git checkout current_release<br> $ git merge master<br> $ git push github current_release<br> $ cap production deploy </code></p></li> <li><p>I tear down my staging environment, lest it somehow get indexed by a search engine.</p> <p><code> $ git staging teardown </code></p></li> </ol>
    singulars
    1. This table or related slice is empty.
    1. POGit / Rails / Shared Hosting (Dreamhost) workflow
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USAndres Jaan Tack
    1. USAndres Jaan Tack
    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