StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>Jeremy's answer (+1) is already quite comprehensive. Some additional more practical-oriented advice follows in <em>no particular order</em>.</p> <p><strong><em>Disclaimer:</em></strong> this is stuff that works for me. Others might have other suggestion or even disagree. If this is the case I would be superhappy to hear feedback and alternate/better proposals!</p> <ol> <li><p><strong>Make a point that every team member should start his/her session by updating the code AND database.</strong> You can easily script all of that with a combination of <code>ssh</code> and <code>rsync</code> commands. I at times create a single script (<code>update-project.sh</code>) that updates the code from the repository and download and import the latest DB from the master server at once.</p></li> <li><p><strong>Never forget to call <code>http://example.com/update.php</code> every time you update the code.</strong> Run this command on your staging site, after every commit, and on your local machine after every update/pull/checkout.</p></li> <li><p><strong>Do any change to the DB via SQL query, rather than with a GUI.</strong> That way you will simply have to wrap that query into an <a href="http://api.drupal.org/api/function/hook_update_N/6" rel="noreferrer"><code>hook_update_N()</code></a> implementation in your <em>yourmodule.install</em> file, and you are safe and sound (if you abide to point #2!) [some gui tool output the equivalent... that's handy too!].</p></li> <li><p><strong>Whenever possible, include in <a href="http://api.drupal.org/api/function/hook_update_N/6" rel="noreferrer"><code>hook_update_N()</code></a> also changes to module settings.</strong> This is not possible all the times. When not possible: see point #7 and #8.</p></li> <li><p><strong>When creating or modifying a view, export it to a file when finished.</strong> Same principle that point #3 but applied to views. This approach has incidentally also the benefit of providing a rollback mechanism in case you later realise you made a mistake.</p></li> <li><p><strong>Use a master repository.</strong> Don't go for a too much distributed versioning system. Pull and push your code always from the same central repo.</p></li> <li><p><strong>Always include a comment in your commit.</strong> Especially if some code change change some functionality / API / common logic, make a point to include a warning in your commit message. Detailed info can be put in a changelog.txt file, if needed.</p></li> <li><p><strong>When committing, immediately reproduce on the master DB any hand-made DB changes that you haven't managed to include in your <code>hook_update_N()</code> implementation.</strong> This is a must if your team members start their sessions like described in #1.</p></li> <li><p><strong>Be selective in what you put under versioning.</strong> For example: exclude the <code>sites/default/settings.php</code> but evaluate what (if anything at all) need to be versioned from in <code>sites/default/files</code> (are images needed for development? and attachments?).</p></li> <li><p><strong>There are some useful contributed modules that can help.</strong> Like <a href="http://drupal.org/project/import_export_tool" rel="noreferrer">import/export</a>, which allows you to manage in a repository your CCK and Views or <a href="http://drupal.org/project/node_export" rel="noreferrer">node export</a> that allows you to export nodes and then import them back in another drupal installation.</p></li> <li><p><strong>Use the <a href="http://drupal.org/project/simpletest" rel="noreferrer">simpletest module</a> extensively.</strong> That is a <strong>good</strong> idea anyhow, but when working in team is a <strong>great</strong> idea: that way you will be sure your changes haven't broken anybody else's work.</p></li> <li><p><strong>Have fun!</strong> I love to work in team and I believe one should try to do that everytime he/she can. It's more fun, more learning and above all... better code! :)</p></li> </ol> <p>Bonus point (does not refer to team development specifically):</p> <ul> <li><strong>Try not to use your staging server for real content insertion.</strong> Ideally you should start creating content only when the code is somehow freezed or use an import routing/module: drupal scatters information across tables a lot, and the system of hooks makes very difficult to track which modules have stored what information where: if you develop on a DB with real data, you will inevitably end up breaking some tables at some point, and you might realise that only the day before going into production. :(</li> </ul>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

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