https://wiki.wormbase.org/api.php?action=feedcontributions&user=Acabunoc&feedformat=atomWormBaseWiki - User contributions [en]2024-03-28T13:46:42ZUser contributionsMediaWiki 1.33.0https://wiki.wormbase.org/index.php?title=Website:WormMine_Builds&diff=24460Website:WormMine Builds2014-08-12T18:27:50Z<p>Acabunoc: </p>
<hr />
<div>=== WS244 ===<br />
<br />
==== Build ====<br />
<br />
===== AceDB Dump =====<br />
<br />
Host: dev.wormbase.org<br />
<br />
User: intermine<br />
<br />
Path: <code> /home/intermine</code><br />
<br />
Command: <code>./website-intermine/scripts/dump_ace.sh /mnt/ephemeral0/acedb_dump_ws244</code><br />
<br />
Note: DO NOT add a trailing backslash after the path<br />
<br />
Output<br />
<br />
<pre><br />
./website-intermine/scripts/dump_ace.sh /mnt/ephemeral0/acedb_dump_ws244<br />
Did not specify AceDB dir in $ACEDB. Searching for tace...<br />
ACEDB set to: /usr/local/wormbase/acedb/wormbase<br />
Transcript<br />
<br />
... done.<br />
Variation<br />
... done.<br />
Phenotype<br />
... done.<br />
Expr_pattern<br />
... done.<br />
Expression_cluster<br />
... done.<br />
Anatomy_term<br />
... done.<br />
Expr_cluster<br />
... done.<br />
Life_stage<br />
... done.<br />
RNAi<br />
... done.<br />
<br />
**** Program tace, compiled on: May 14 2010 09:21:02 ****<br />
**** Using ACEDB 4.9.52, compiled on: May 14 2010 09:20:07 ****<br />
<br />
Code by: Jean Thierry-Mieg (CNRS, France) mieg@crbm.cnrs-mop.fr<br />
Richard Durbin (Sanger Centre, UK) rd@sanger.ac.uk<br />
Ed Griffiths (Sanger Centre, UK) edgrif@sanger.ac.uk<br />
<br />
You may redistribute this program and database subject to the<br />
conditions in the accompanying copyright file. Anyone interested in<br />
maintaining an up-to-date version should contact one of the authors<br />
at the above email addresses.<br />
<br />
// Database directory: /usr/local/wormbase/acedb/wormbase<br />
// Session 594 is readlocked by acabunoc since 2014-08-11_18:29:04 using tace (process 31767 on machine dev.wormbase.org)<br />
// Session 594 is readlocked by getLoginFailed since 2014-08-11_19:28:09 using tace (process 672 on machine dev.wormbase.org)<br />
acedb> <br />
// Found 223435 objects<br />
// 223435 Active Objects<br />
acedb> // 223435 objects dumped<br />
// 223435 Active Objects<br />
acedb> <br />
// Found 199169 objects<br />
// 199169 Active Objects<br />
acedb> // 199169 objects dumped<br />
// 199169 Active Objects<br />
acedb> <br />
// Found 201722 objects<br />
// 201722 Active Objects<br />
acedb> // 201722 objects dumped<br />
// 201722 Active Objects<br />
acedb> <br />
// Found 239936 objects<br />
// 239936 Active Objects<br />
acedb> // 239936 objects dumped<br />
// 239936 Active Objects<br />
acedb> // ERROR - Failed to open for reading: /home/intermine/website-intermine/acedb-dev/acedb/species.ace (system error 2 - No such file or directory)<br />
// Sorry, I could not open file /home/intermine/website-intermine/acedb-dev/acedb/species.ace<br />
// 239936 Active Objects<br />
acedb> // 239936 objects dumped<br />
// 239936 Active Objects<br />
acedb> // 239936 Active Objects<br />
acedb> <br />
// A bientot<br />
</pre><br />
<br />
<br />
<br />
===== Pre-Processing =====<br />
<br />
Host: WormMine dev server (206.108.125.174)<br />
<br />
User: intermine<br />
<br />
Path: <code>/nfs/wormbase/data/acedmp</code><br />
<br />
Commands:<br />
<br />
<pre><br />
mkdir WS244<br />
cd WS244<br />
scp acabunoc@dev.wormbase.org:/mnt/ephemeral0/acedb_dump_ws244/* .<br />
cd /home/intermine/website-intermine/acedb-dev/intermine/redeployment<br />
# Set "release = WS244" in update.properties<br />
ant<br />
</pre><br />
<br />
Build failed with error:<br />
<code>/nfs/wormbase/data/intermine/redeployment/build.xml:68: Property 'bpid-c_sp11' is not defined.</code><br />
<br />
Fixed by changing c_sp11 to c_tropicalis in <code>genomic-fasta-species.txt</code>, <code>protein-fasta-species.txt</code> and <code>gff3-species.txt</code><br />
<br />
<br />
<br />
<br />
===== InterMine Build =====<br />
<br />
Host: WormMine dev server (206.108.125.174)<br />
<br />
User: intermine<br />
<br />
Path: <code>/home/intermine/website-intermine</code><br />
<br />
Command: <code>./scripts/build_intermine.sh WS240</code><br />
<br />
Output (stdout, stderr not shown):<br />
<br />
<pre><br />
USING RELEASE: WS244<br />
DATABASE NAME: wormmine_ws244<br />
Updating ~/.intermine/wormmine.properties...<br />
Updating project.xml...<br />
Building the InterMine database...<br />
</pre><br />
<br />
<span style="color: red">'''Quick fix for resolving missing organisms.xml file:'''</span><br />
<br />
<pre><br />
cd /nfs/wormbase/data/intermine/datadir<br />
mkdir entrez-organism<br />
cp /home/intermine/organisms.xml entrez-organism<br />
</pre><br />
<br />
<br />
<br />
=== WS240 ===<br />
<br />
==== Build ====<br />
<br />
===== ACeDB Dump =====<br />
<br />
Host: Website dev server<br />
<br />
User: intermine<br />
<br />
Path: <code>/home/intermine</code><br />
<br />
Command: <code>./website-intermine/scripts/dump_ace.sh /mnt/ephemeral0/acedb_dump_ws240</code><br />
<br />
Output:<br />
<br />
<pre><br />
Did not specify AceDB dir in $ACEDB. Searching for tace...<br />
ACEDB set to: /usr/local/wormbase/acedb/wormbase<br />
Transcript<br />
... done.<br />
Variation<br />
... done.<br />
Phenotype<br />
... done.<br />
Expr_pattern<br />
... done.<br />
Expression_cluster<br />
... done.<br />
Anatomy_term<br />
... done.<br />
Expr_cluster<br />
... done.<br />
Life_stage<br />
... done.<br />
RNAi<br />
... done.<br />
<br />
**** Program tace, compiled on: May 14 2010 09:21:02 ****<br />
**** Using ACEDB 4.9.52, compiled on: May 14 2010 09:20:07 ****<br />
<br />
Code by: Jean Thierry-Mieg (CNRS, France) mieg@crbm.cnrs-mop.fr<br />
Richard Durbin (Sanger Centre, UK) rd@sanger.ac.uk<br />
Ed Griffiths (Sanger Centre, UK) edgrif@sanger.ac.uk<br />
<br />
You may redistribute this program and database subject to the<br />
conditions in the accompanying copyright file. Anyone interested in<br />
maintaining an up-to-date version should contact one of the authors<br />
at the above email addresses.<br />
<br />
// Database directory: /usr/local/wormbase/acedb/wormbase<br />
acedb><br />
// Found 204526 objects<br />
// 204526 Active Objects<br />
acedb> // 204526 objects dumped<br />
// 204526 Active Objects<br />
acedb><br />
// Found 186343 objects<br />
// 186343 Active Objects<br />
acedb> // 186343 objects dumped<br />
// 186343 Active Objects<br />
acedb><br />
// Found 188862 objects<br />
// 188862 Active Objects<br />
acedb> // 188862 objects dumped<br />
// 188862 Active Objects<br />
acedb><br />
// Found 221196 objects<br />
// 221196 Active Objects<br />
acedb> // 221196 objects dumped<br />
// 221196 Active Objects<br />
acedb> // ERROR - Failed to open for reading: /home/jbaran/src/website-intermine/acedb-dev/acedb/species.ace (system error 2 - No such file or directory)<br />
// Sorry, I could not open file /home/jbaran/src/website-intermine/acedb-dev/acedb/species.ace<br />
// 221196 Active Objects<br />
acedb> // 221196 objects dumped<br />
// 221196 Active Objects<br />
acedb> // 221196 Active Objects<br />
acedb><br />
// A bientot<br />
</pre><br />
<br />
===== Pre-Processing =====<br />
<br />
Host: WormMine dev server (206.108.125.174)<br />
<br />
User: intermine<br />
<br />
Path: <code>/nfs/wormbase/data/acedmp</code><br />
<br />
Commands:<br />
<br />
<pre><br />
mkdir WS240<br />
cd WS240<br />
scp jbaran@dev.wormbase.org:/mnt/ephemeral0/acedb_dump_ws240/* .<br />
cd /home/intermine/website-intermine/acedb-dev/intermine/redeployment<br />
# Set "release = WS240" in update.properties<br />
ant<br />
</pre><br />
<br />
Output: ''too long to show here''<br />
<br />
===== InterMine Build =====<br />
<br />
Host: WormMine dev server (206.108.125.174)<br />
<br />
User: intermine<br />
<br />
Path: <code>/home/intermine/website-intermine</code><br />
<br />
Command: <code>./scripts/build_intermine.sh WS240</code><br />
<br />
Output (stdout, stderr not shown):<br />
<br />
<pre><br />
USING RELEASE: WS240<br />
DATABASE NAME: wormmine_ws240<br />
Updating ~/.intermine/wormmine.properties...<br />
Updating project.xml...<br />
Building the InterMine database...<br />
<br />
action name time in seconds<br />
-------------------------------------------------------------<br />
entrez-organism 130<br />
create-chromosome-locations-and-lengths 1075<br />
do-sources 51<br />
create-search-index 3747<br />
summarise-objectstore 740<br />
create-autocomplete-index 41<br />
create-attribute-indexes 191<br />
transfer-sequences 209663<br />
final-dump 1246<br />
<br />
total 216884<br />
</pre><br />
<br />
<span style="color: red">'''Quick fix for resolving missing organisms.xml file:'''</span><br />
<br />
<pre><br />
cd /nfs/wormbase/data/intermine/datadir<br />
mkdir entrez-organism<br />
cp /home/intermine/organisms.xml entrez-organism<br />
</pre><br />
<br />
===== Deployment =====<br />
<br />
TBD<br />
<br />
=== WS239 ===<br />
<br />
==== Build ====<br />
<br />
Host: WormMine dev server (206.108.125.174)<br />
<br />
Path: <code>/home/jbaran/src/website-intermine/acedb-dev/intermine/wormmine</code><br />
<br />
Command: <code>../bio/scripts/project_build -l -v localhost joachim_ws239_2</code><br />
<br />
Summary:<br />
<br />
<pre><br />
action name time in seconds<br />
-------------------------------------------------------------<br />
entrez-organism 95<br />
create-chromosome-locations-and-lengths 708<br />
do-sources 25<br />
create-search-index 983<br />
summarise-objectstore 245<br />
create-autocomplete-index 28<br />
create-attribute-indexes 95<br />
transfer-sequences 248429<br />
final-dump 697<br />
<br />
total 251305<br />
</pre><br />
<br />
==== Deployment ====<br />
<br />
Host: WormMine production server (206.108.125.166)<br />
<br />
Path: <code>/nfs/wormbase/archive/jbaran/WS239-2</code><br />
<br />
Commands:<br />
<br />
<pre><br />
dropdb -U intermine joachim-ws239-2<br />
createdb -U intermine -E SQL_ASCII joachim-ws239-2<br />
pg_restore -U intermine_admin -d joachim-ws239-2 joachim_ws239_2.final<br />
</pre><br />
<br />
Required Disk Space:<br />
<br />
1.3G joachim_ws239_2.final + 17G PostgreSQL DB<br />
<br />
[[Category: Architecture (Web Dev)]]</div>Acabunochttps://wiki.wormbase.org/index.php?title=Website:WormMine_Builds&diff=24459Website:WormMine Builds2014-08-12T18:02:56Z<p>Acabunoc: </p>
<hr />
<div>=== WS244 ===<br />
<br />
==== Build ====<br />
<br />
===== AceDB Dump =====<br />
<br />
Host: dev.wormbase.org<br />
<br />
User: intermine<br />
<br />
Path: <code> /home/intermine</code><br />
<br />
Command: <code>./website-intermine/scripts/dump_ace.sh /mnt/ephemeral0/acedb_dump_ws244</code><br />
<br />
Note: DO NOT add a trailing backslash after the path<br />
<br />
Output<br />
<br />
<pre><br />
./website-intermine/scripts/dump_ace.sh /mnt/ephemeral0/acedb_dump_ws244<br />
Did not specify AceDB dir in $ACEDB. Searching for tace...<br />
ACEDB set to: /usr/local/wormbase/acedb/wormbase<br />
Transcript<br />
<br />
... done.<br />
Variation<br />
... done.<br />
Phenotype<br />
... done.<br />
Expr_pattern<br />
... done.<br />
Expression_cluster<br />
... done.<br />
Anatomy_term<br />
... done.<br />
Expr_cluster<br />
... done.<br />
Life_stage<br />
... done.<br />
RNAi<br />
... done.<br />
<br />
**** Program tace, compiled on: May 14 2010 09:21:02 ****<br />
**** Using ACEDB 4.9.52, compiled on: May 14 2010 09:20:07 ****<br />
<br />
Code by: Jean Thierry-Mieg (CNRS, France) mieg@crbm.cnrs-mop.fr<br />
Richard Durbin (Sanger Centre, UK) rd@sanger.ac.uk<br />
Ed Griffiths (Sanger Centre, UK) edgrif@sanger.ac.uk<br />
<br />
You may redistribute this program and database subject to the<br />
conditions in the accompanying copyright file. Anyone interested in<br />
maintaining an up-to-date version should contact one of the authors<br />
at the above email addresses.<br />
<br />
// Database directory: /usr/local/wormbase/acedb/wormbase<br />
// Session 594 is readlocked by acabunoc since 2014-08-11_18:29:04 using tace (process 31767 on machine dev.wormbase.org)<br />
// Session 594 is readlocked by getLoginFailed since 2014-08-11_19:28:09 using tace (process 672 on machine dev.wormbase.org)<br />
acedb> <br />
// Found 223435 objects<br />
// 223435 Active Objects<br />
acedb> // 223435 objects dumped<br />
// 223435 Active Objects<br />
acedb> <br />
// Found 199169 objects<br />
// 199169 Active Objects<br />
acedb> // 199169 objects dumped<br />
// 199169 Active Objects<br />
acedb> <br />
// Found 201722 objects<br />
// 201722 Active Objects<br />
acedb> // 201722 objects dumped<br />
// 201722 Active Objects<br />
acedb> <br />
// Found 239936 objects<br />
// 239936 Active Objects<br />
acedb> // 239936 objects dumped<br />
// 239936 Active Objects<br />
acedb> // ERROR - Failed to open for reading: /home/intermine/website-intermine/acedb-dev/acedb/species.ace (system error 2 - No such file or directory)<br />
// Sorry, I could not open file /home/intermine/website-intermine/acedb-dev/acedb/species.ace<br />
// 239936 Active Objects<br />
acedb> // 239936 objects dumped<br />
// 239936 Active Objects<br />
acedb> // 239936 Active Objects<br />
acedb> <br />
// A bientot<br />
</pre><br />
<br />
<br />
<br />
===== Pre-Processing =====<br />
<br />
Host: WormMine dev server (206.108.125.174)<br />
<br />
User: intermine<br />
<br />
Path: <code>/nfs/wormbase/data/acedmp</code><br />
<br />
Commands:<br />
<br />
<pre><br />
mkdir WS244<br />
cd WS244<br />
scp acabunoc@dev.wormbase.org:/mnt/ephemeral0/acedb_dump_ws244/* .<br />
cd /home/intermine/website-intermine/acedb-dev/intermine/redeployment<br />
# Set "release = WS244" in update.properties<br />
ant<br />
</pre><br />
<br />
Build failed with error:<br />
<code>/nfs/wormbase/data/intermine/redeployment/build.xml:68: Property 'bpid-c_sp11' is not defined.</code><br />
<br />
Fixed by changing c_sp11 to c_tropicalis in <code>genomic-fasta-species.txt</code>, <code>protein-fasta-species.txt</code> and <code>gff3-species.txt</code><br />
<br />
<br />
<br />
<br />
===== InterMine Build =====<br />
<br />
Host: WormMine dev server (206.108.125.174)<br />
<br />
User: intermine<br />
<br />
Path: <code>/home/intermine/website-intermine</code><br />
<br />
Command: <code>./scripts/build_intermine.sh WS240</code><br />
<br />
Output (stdout, stderr not shown):<br />
<br />
<pre><br />
USING RELEASE: WS244<br />
DATABASE NAME: wormmine_ws244<br />
Updating ~/.intermine/wormmine.properties...<br />
Updating project.xml...<br />
Building the InterMine database...<br />
<br />
<br />
<br />
<br />
=== WS240 ===<br />
<br />
==== Build ====<br />
<br />
===== ACeDB Dump =====<br />
<br />
Host: Website dev server<br />
<br />
User: intermine<br />
<br />
Path: <code>/home/intermine</code><br />
<br />
Command: <code>./website-intermine/scripts/dump_ace.sh /mnt/ephemeral0/acedb_dump_ws240</code><br />
<br />
Output:<br />
<br />
<pre><br />
Did not specify AceDB dir in $ACEDB. Searching for tace...<br />
ACEDB set to: /usr/local/wormbase/acedb/wormbase<br />
Transcript<br />
... done.<br />
Variation<br />
... done.<br />
Phenotype<br />
... done.<br />
Expr_pattern<br />
... done.<br />
Expression_cluster<br />
... done.<br />
Anatomy_term<br />
... done.<br />
Expr_cluster<br />
... done.<br />
Life_stage<br />
... done.<br />
RNAi<br />
... done.<br />
<br />
**** Program tace, compiled on: May 14 2010 09:21:02 ****<br />
**** Using ACEDB 4.9.52, compiled on: May 14 2010 09:20:07 ****<br />
<br />
Code by: Jean Thierry-Mieg (CNRS, France) mieg@crbm.cnrs-mop.fr<br />
Richard Durbin (Sanger Centre, UK) rd@sanger.ac.uk<br />
Ed Griffiths (Sanger Centre, UK) edgrif@sanger.ac.uk<br />
<br />
You may redistribute this program and database subject to the<br />
conditions in the accompanying copyright file. Anyone interested in<br />
maintaining an up-to-date version should contact one of the authors<br />
at the above email addresses.<br />
<br />
// Database directory: /usr/local/wormbase/acedb/wormbase<br />
acedb><br />
// Found 204526 objects<br />
// 204526 Active Objects<br />
acedb> // 204526 objects dumped<br />
// 204526 Active Objects<br />
acedb><br />
// Found 186343 objects<br />
// 186343 Active Objects<br />
acedb> // 186343 objects dumped<br />
// 186343 Active Objects<br />
acedb><br />
// Found 188862 objects<br />
// 188862 Active Objects<br />
acedb> // 188862 objects dumped<br />
// 188862 Active Objects<br />
acedb><br />
// Found 221196 objects<br />
// 221196 Active Objects<br />
acedb> // 221196 objects dumped<br />
// 221196 Active Objects<br />
acedb> // ERROR - Failed to open for reading: /home/jbaran/src/website-intermine/acedb-dev/acedb/species.ace (system error 2 - No such file or directory)<br />
// Sorry, I could not open file /home/jbaran/src/website-intermine/acedb-dev/acedb/species.ace<br />
// 221196 Active Objects<br />
acedb> // 221196 objects dumped<br />
// 221196 Active Objects<br />
acedb> // 221196 Active Objects<br />
acedb><br />
// A bientot<br />
</pre><br />
<br />
===== Pre-Processing =====<br />
<br />
Host: WormMine dev server (206.108.125.174)<br />
<br />
User: intermine<br />
<br />
Path: <code>/nfs/wormbase/data/acedmp</code><br />
<br />
Commands:<br />
<br />
<pre><br />
mkdir WS240<br />
cd WS240<br />
scp jbaran@dev.wormbase.org:/mnt/ephemeral0/acedb_dump_ws240/* .<br />
cd /home/intermine/website-intermine/acedb-dev/intermine/redeployment<br />
# Set "release = WS240" in update.properties<br />
ant<br />
</pre><br />
<br />
Output: ''too long to show here''<br />
<br />
===== InterMine Build =====<br />
<br />
Host: WormMine dev server (206.108.125.174)<br />
<br />
User: intermine<br />
<br />
Path: <code>/home/intermine/website-intermine</code><br />
<br />
Command: <code>./scripts/build_intermine.sh WS240</code><br />
<br />
Output (stdout, stderr not shown):<br />
<br />
<pre><br />
USING RELEASE: WS240<br />
DATABASE NAME: wormmine_ws240<br />
Updating ~/.intermine/wormmine.properties...<br />
Updating project.xml...<br />
Building the InterMine database...<br />
<br />
action name time in seconds<br />
-------------------------------------------------------------<br />
entrez-organism 130<br />
create-chromosome-locations-and-lengths 1075<br />
do-sources 51<br />
create-search-index 3747<br />
summarise-objectstore 740<br />
create-autocomplete-index 41<br />
create-attribute-indexes 191<br />
transfer-sequences 209663<br />
final-dump 1246<br />
<br />
total 216884<br />
</pre><br />
<br />
<span style="color: red">'''Quick fix for resolving missing organisms.xml file:'''</span><br />
<br />
<pre><br />
cd /nfs/wormbase/data/intermine/datadir<br />
mkdir entrez-organism<br />
cp /home/intermine/organisms.xml entrez-organism<br />
</pre><br />
<br />
===== Deployment =====<br />
<br />
TBD<br />
<br />
=== WS239 ===<br />
<br />
==== Build ====<br />
<br />
Host: WormMine dev server (206.108.125.174)<br />
<br />
Path: <code>/home/jbaran/src/website-intermine/acedb-dev/intermine/wormmine</code><br />
<br />
Command: <code>../bio/scripts/project_build -l -v localhost joachim_ws239_2</code><br />
<br />
Summary:<br />
<br />
<pre><br />
action name time in seconds<br />
-------------------------------------------------------------<br />
entrez-organism 95<br />
create-chromosome-locations-and-lengths 708<br />
do-sources 25<br />
create-search-index 983<br />
summarise-objectstore 245<br />
create-autocomplete-index 28<br />
create-attribute-indexes 95<br />
transfer-sequences 248429<br />
final-dump 697<br />
<br />
total 251305<br />
</pre><br />
<br />
==== Deployment ====<br />
<br />
Host: WormMine production server (206.108.125.166)<br />
<br />
Path: <code>/nfs/wormbase/archive/jbaran/WS239-2</code><br />
<br />
Commands:<br />
<br />
<pre><br />
dropdb -U intermine joachim-ws239-2<br />
createdb -U intermine -E SQL_ASCII joachim-ws239-2<br />
pg_restore -U intermine_admin -d joachim-ws239-2 joachim_ws239_2.final<br />
</pre><br />
<br />
Required Disk Space:<br />
<br />
1.3G joachim_ws239_2.final + 17G PostgreSQL DB<br />
<br />
[[Category: Architecture (Web Dev)]]</div>Acabunochttps://wiki.wormbase.org/index.php?title=Website:WormMine_Builds&diff=24450Website:WormMine Builds2014-08-12T16:49:30Z<p>Acabunoc: </p>
<hr />
<div>=== WS244 ===<br />
<br />
==== Build ====<br />
<br />
===== AceDB Dump =====<br />
<br />
Host: dev.wormbase.org<br />
<br />
User: intermine<br />
<br />
Path: <code> /home/intermine</code><br />
<br />
Command: <code>./website-intermine/scripts/dump_ace.sh /mnt/ephemeral0/acedb_dump_ws244</code><br />
<br />
Note: DO NOT add a trailing backslash after the path<br />
<br />
Output<br />
<br />
<pre><br />
./website-intermine/scripts/dump_ace.sh /mnt/ephemeral0/acedb_dump_ws244<br />
Did not specify AceDB dir in $ACEDB. Searching for tace...<br />
ACEDB set to: /usr/local/wormbase/acedb/wormbase<br />
Transcript<br />
<br />
... done.<br />
Variation<br />
... done.<br />
Phenotype<br />
... done.<br />
Expr_pattern<br />
... done.<br />
Expression_cluster<br />
... done.<br />
Anatomy_term<br />
... done.<br />
Expr_cluster<br />
... done.<br />
Life_stage<br />
... done.<br />
RNAi<br />
... done.<br />
<br />
**** Program tace, compiled on: May 14 2010 09:21:02 ****<br />
**** Using ACEDB 4.9.52, compiled on: May 14 2010 09:20:07 ****<br />
<br />
Code by: Jean Thierry-Mieg (CNRS, France) mieg@crbm.cnrs-mop.fr<br />
Richard Durbin (Sanger Centre, UK) rd@sanger.ac.uk<br />
Ed Griffiths (Sanger Centre, UK) edgrif@sanger.ac.uk<br />
<br />
You may redistribute this program and database subject to the<br />
conditions in the accompanying copyright file. Anyone interested in<br />
maintaining an up-to-date version should contact one of the authors<br />
at the above email addresses.<br />
<br />
// Database directory: /usr/local/wormbase/acedb/wormbase<br />
// Session 594 is readlocked by acabunoc since 2014-08-11_18:29:04 using tace (process 31767 on machine dev.wormbase.org)<br />
// Session 594 is readlocked by getLoginFailed since 2014-08-11_19:28:09 using tace (process 672 on machine dev.wormbase.org)<br />
acedb> <br />
// Found 223435 objects<br />
// 223435 Active Objects<br />
acedb> // 223435 objects dumped<br />
// 223435 Active Objects<br />
acedb> <br />
// Found 199169 objects<br />
// 199169 Active Objects<br />
acedb> // 199169 objects dumped<br />
// 199169 Active Objects<br />
acedb> <br />
// Found 201722 objects<br />
// 201722 Active Objects<br />
acedb> // 201722 objects dumped<br />
// 201722 Active Objects<br />
acedb> <br />
// Found 239936 objects<br />
// 239936 Active Objects<br />
acedb> // 239936 objects dumped<br />
// 239936 Active Objects<br />
acedb> // ERROR - Failed to open for reading: /home/intermine/website-intermine/acedb-dev/acedb/species.ace (system error 2 - No such file or directory)<br />
// Sorry, I could not open file /home/intermine/website-intermine/acedb-dev/acedb/species.ace<br />
// 239936 Active Objects<br />
acedb> // 239936 objects dumped<br />
// 239936 Active Objects<br />
acedb> // 239936 Active Objects<br />
acedb> <br />
// A bientot<br />
</pre><br />
<br />
<br />
<br />
===== Pre-Processing =====<br />
<br />
Host: WormMine dev server (206.108.125.174)<br />
<br />
User: intermine<br />
<br />
Path: <code>/nfs/wormbase/data/acedmp</code><br />
<br />
Commands:<br />
<br />
<pre><br />
mkdir WS244<br />
cd WS244<br />
scp acabunoc@dev.wormbase.org:/mnt/ephemeral0/acedb_dump_ws244/* .<br />
cd /home/intermine/website-intermine/acedb-dev/intermine/redeployment<br />
# Set "release = WS244" in update.properties<br />
ant<br />
</pre><br />
<br />
Build failed with error:<br />
<code>/nfs/wormbase/data/intermine/redeployment/build.xml:68: Property 'bpid-c_sp11' is not defined.</code><br />
<br />
Fixed by changing c_sp11 to c_tropicalis in <code>genomic-fasta-species.txt</code>, <code>protein-fasta-species.txt</code> and <code>gff3-species.txt</code><br />
<br />
<br />
<br />
=== WS240 ===<br />
<br />
==== Build ====<br />
<br />
===== ACeDB Dump =====<br />
<br />
Host: Website dev server<br />
<br />
User: intermine<br />
<br />
Path: <code>/home/intermine</code><br />
<br />
Command: <code>./website-intermine/scripts/dump_ace.sh /mnt/ephemeral0/acedb_dump_ws240</code><br />
<br />
Output:<br />
<br />
<pre><br />
Did not specify AceDB dir in $ACEDB. Searching for tace...<br />
ACEDB set to: /usr/local/wormbase/acedb/wormbase<br />
Transcript<br />
... done.<br />
Variation<br />
... done.<br />
Phenotype<br />
... done.<br />
Expr_pattern<br />
... done.<br />
Expression_cluster<br />
... done.<br />
Anatomy_term<br />
... done.<br />
Expr_cluster<br />
... done.<br />
Life_stage<br />
... done.<br />
RNAi<br />
... done.<br />
<br />
**** Program tace, compiled on: May 14 2010 09:21:02 ****<br />
**** Using ACEDB 4.9.52, compiled on: May 14 2010 09:20:07 ****<br />
<br />
Code by: Jean Thierry-Mieg (CNRS, France) mieg@crbm.cnrs-mop.fr<br />
Richard Durbin (Sanger Centre, UK) rd@sanger.ac.uk<br />
Ed Griffiths (Sanger Centre, UK) edgrif@sanger.ac.uk<br />
<br />
You may redistribute this program and database subject to the<br />
conditions in the accompanying copyright file. Anyone interested in<br />
maintaining an up-to-date version should contact one of the authors<br />
at the above email addresses.<br />
<br />
// Database directory: /usr/local/wormbase/acedb/wormbase<br />
acedb><br />
// Found 204526 objects<br />
// 204526 Active Objects<br />
acedb> // 204526 objects dumped<br />
// 204526 Active Objects<br />
acedb><br />
// Found 186343 objects<br />
// 186343 Active Objects<br />
acedb> // 186343 objects dumped<br />
// 186343 Active Objects<br />
acedb><br />
// Found 188862 objects<br />
// 188862 Active Objects<br />
acedb> // 188862 objects dumped<br />
// 188862 Active Objects<br />
acedb><br />
// Found 221196 objects<br />
// 221196 Active Objects<br />
acedb> // 221196 objects dumped<br />
// 221196 Active Objects<br />
acedb> // ERROR - Failed to open for reading: /home/jbaran/src/website-intermine/acedb-dev/acedb/species.ace (system error 2 - No such file or directory)<br />
// Sorry, I could not open file /home/jbaran/src/website-intermine/acedb-dev/acedb/species.ace<br />
// 221196 Active Objects<br />
acedb> // 221196 objects dumped<br />
// 221196 Active Objects<br />
acedb> // 221196 Active Objects<br />
acedb><br />
// A bientot<br />
</pre><br />
<br />
===== Pre-Processing =====<br />
<br />
Host: WormMine dev server (206.108.125.174)<br />
<br />
User: intermine<br />
<br />
Path: <code>/nfs/wormbase/data/acedmp</code><br />
<br />
Commands:<br />
<br />
<pre><br />
mkdir WS240<br />
cd WS240<br />
scp jbaran@dev.wormbase.org:/mnt/ephemeral0/acedb_dump_ws240/* .<br />
cd /home/intermine/website-intermine/acedb-dev/intermine/redeployment<br />
# Set "release = WS240" in update.properties<br />
ant<br />
</pre><br />
<br />
Output: ''too long to show here''<br />
<br />
===== InterMine Build =====<br />
<br />
Host: WormMine dev server (206.108.125.174)<br />
<br />
User: intermine<br />
<br />
Path: <code>/home/intermine/website-intermine</code><br />
<br />
Command: <code>./scripts/build_intermine.sh WS240</code><br />
<br />
Output (stdout, stderr not shown):<br />
<br />
<pre><br />
USING RELEASE: WS240<br />
DATABASE NAME: wormmine_ws240<br />
Updating ~/.intermine/wormmine.properties...<br />
Updating project.xml...<br />
Building the InterMine database...<br />
<br />
action name time in seconds<br />
-------------------------------------------------------------<br />
entrez-organism 130<br />
create-chromosome-locations-and-lengths 1075<br />
do-sources 51<br />
create-search-index 3747<br />
summarise-objectstore 740<br />
create-autocomplete-index 41<br />
create-attribute-indexes 191<br />
transfer-sequences 209663<br />
final-dump 1246<br />
<br />
total 216884<br />
</pre><br />
<br />
<span style="color: red">'''Quick fix for resolving missing organisms.xml file:'''</span><br />
<br />
<pre><br />
cd /nfs/wormbase/data/intermine/datadir<br />
mkdir entrez-organism<br />
cp /home/intermine/organisms.xml entrez-organism<br />
</pre><br />
<br />
===== Deployment =====<br />
<br />
TBD<br />
<br />
=== WS239 ===<br />
<br />
==== Build ====<br />
<br />
Host: WormMine dev server (206.108.125.174)<br />
<br />
Path: <code>/home/jbaran/src/website-intermine/acedb-dev/intermine/wormmine</code><br />
<br />
Command: <code>../bio/scripts/project_build -l -v localhost joachim_ws239_2</code><br />
<br />
Summary:<br />
<br />
<pre><br />
action name time in seconds<br />
-------------------------------------------------------------<br />
entrez-organism 95<br />
create-chromosome-locations-and-lengths 708<br />
do-sources 25<br />
create-search-index 983<br />
summarise-objectstore 245<br />
create-autocomplete-index 28<br />
create-attribute-indexes 95<br />
transfer-sequences 248429<br />
final-dump 697<br />
<br />
total 251305<br />
</pre><br />
<br />
==== Deployment ====<br />
<br />
Host: WormMine production server (206.108.125.166)<br />
<br />
Path: <code>/nfs/wormbase/archive/jbaran/WS239-2</code><br />
<br />
Commands:<br />
<br />
<pre><br />
dropdb -U intermine joachim-ws239-2<br />
createdb -U intermine -E SQL_ASCII joachim-ws239-2<br />
pg_restore -U intermine_admin -d joachim-ws239-2 joachim_ws239_2.final<br />
</pre><br />
<br />
Required Disk Space:<br />
<br />
1.3G joachim_ws239_2.final + 17G PostgreSQL DB<br />
<br />
[[Category: Architecture (Web Dev)]]</div>Acabunochttps://wiki.wormbase.org/index.php?title=Website:WormMine_Builds&diff=24443Website:WormMine Builds2014-08-12T15:54:00Z<p>Acabunoc: </p>
<hr />
<div>=== WS244 ===<br />
<br />
==== Build ====<br />
<br />
===== AceDB Dump =====<br />
<br />
Host: dev.wormbase.org<br />
<br />
User: intermine<br />
<br />
Path: <code> /home/intermine</code><br />
<br />
Command: <code>./website-intermine/scripts/dump_ace.sh /mnt/ephemeral0/acedb_dump_ws244</code><br />
<br />
Note: DO NOT add a trailing backslash after the path<br />
<br />
Output<br />
<br />
<pre><br />
./website-intermine/scripts/dump_ace.sh /mnt/ephemeral0/acedb_dump_ws244<br />
Did not specify AceDB dir in $ACEDB. Searching for tace...<br />
ACEDB set to: /usr/local/wormbase/acedb/wormbase<br />
Transcript<br />
<br />
... done.<br />
Variation<br />
... done.<br />
Phenotype<br />
... done.<br />
Expr_pattern<br />
... done.<br />
Expression_cluster<br />
... done.<br />
Anatomy_term<br />
... done.<br />
Expr_cluster<br />
... done.<br />
Life_stage<br />
... done.<br />
RNAi<br />
... done.<br />
<br />
**** Program tace, compiled on: May 14 2010 09:21:02 ****<br />
**** Using ACEDB 4.9.52, compiled on: May 14 2010 09:20:07 ****<br />
<br />
Code by: Jean Thierry-Mieg (CNRS, France) mieg@crbm.cnrs-mop.fr<br />
Richard Durbin (Sanger Centre, UK) rd@sanger.ac.uk<br />
Ed Griffiths (Sanger Centre, UK) edgrif@sanger.ac.uk<br />
<br />
You may redistribute this program and database subject to the<br />
conditions in the accompanying copyright file. Anyone interested in<br />
maintaining an up-to-date version should contact one of the authors<br />
at the above email addresses.<br />
<br />
// Database directory: /usr/local/wormbase/acedb/wormbase<br />
// Session 594 is readlocked by acabunoc since 2014-08-11_18:29:04 using tace (process 31767 on machine dev.wormbase.org)<br />
// Session 594 is readlocked by getLoginFailed since 2014-08-11_19:28:09 using tace (process 672 on machine dev.wormbase.org)<br />
acedb> <br />
// Found 223435 objects<br />
// 223435 Active Objects<br />
acedb> // 223435 objects dumped<br />
// 223435 Active Objects<br />
acedb> <br />
// Found 199169 objects<br />
// 199169 Active Objects<br />
acedb> // 199169 objects dumped<br />
// 199169 Active Objects<br />
acedb> <br />
// Found 201722 objects<br />
// 201722 Active Objects<br />
acedb> // 201722 objects dumped<br />
// 201722 Active Objects<br />
acedb> <br />
// Found 239936 objects<br />
// 239936 Active Objects<br />
acedb> // 239936 objects dumped<br />
// 239936 Active Objects<br />
acedb> // ERROR - Failed to open for reading: /home/intermine/website-intermine/acedb-dev/acedb/species.ace (system error 2 - No such file or directory)<br />
// Sorry, I could not open file /home/intermine/website-intermine/acedb-dev/acedb/species.ace<br />
// 239936 Active Objects<br />
acedb> // 239936 objects dumped<br />
// 239936 Active Objects<br />
acedb> // 239936 Active Objects<br />
acedb> <br />
// A bientot<br />
</pre><br />
<br />
<br />
<br />
===== Pre-Processing =====<br />
<br />
Host: WormMine dev server (206.108.125.174)<br />
<br />
User: intermine<br />
<br />
Path: <code>/nfs/wormbase/data/acedmp</code><br />
<br />
Commands:<br />
<br />
<pre><br />
mkdir WS244<br />
cd WS244<br />
scp acabunoc@dev.wormbase.org:/mnt/ephemeral0/acedb_dump_ws244/* .<br />
cd /home/intermine/website-intermine/acedb-dev/intermine/redeployment<br />
# Set "release = WS244" in update.properties<br />
ant<br />
</pre><br />
<br />
Build failed with error:<br />
<code>/nfs/wormbase/data/intermine/redeployment/build.xml:68: Property 'bpid-c_sp11' is not defined.</code><br />
<br />
Fixed by changing c_sp11 to c_tropicalis in <code>genomic-fasta-species.txt</code> and <code>protein-fasta-species.txt</code><br />
<br />
<br />
<br />
=== WS240 ===<br />
<br />
==== Build ====<br />
<br />
===== ACeDB Dump =====<br />
<br />
Host: Website dev server<br />
<br />
User: intermine<br />
<br />
Path: <code>/home/intermine</code><br />
<br />
Command: <code>./website-intermine/scripts/dump_ace.sh /mnt/ephemeral0/acedb_dump_ws240</code><br />
<br />
Output:<br />
<br />
<pre><br />
Did not specify AceDB dir in $ACEDB. Searching for tace...<br />
ACEDB set to: /usr/local/wormbase/acedb/wormbase<br />
Transcript<br />
... done.<br />
Variation<br />
... done.<br />
Phenotype<br />
... done.<br />
Expr_pattern<br />
... done.<br />
Expression_cluster<br />
... done.<br />
Anatomy_term<br />
... done.<br />
Expr_cluster<br />
... done.<br />
Life_stage<br />
... done.<br />
RNAi<br />
... done.<br />
<br />
**** Program tace, compiled on: May 14 2010 09:21:02 ****<br />
**** Using ACEDB 4.9.52, compiled on: May 14 2010 09:20:07 ****<br />
<br />
Code by: Jean Thierry-Mieg (CNRS, France) mieg@crbm.cnrs-mop.fr<br />
Richard Durbin (Sanger Centre, UK) rd@sanger.ac.uk<br />
Ed Griffiths (Sanger Centre, UK) edgrif@sanger.ac.uk<br />
<br />
You may redistribute this program and database subject to the<br />
conditions in the accompanying copyright file. Anyone interested in<br />
maintaining an up-to-date version should contact one of the authors<br />
at the above email addresses.<br />
<br />
// Database directory: /usr/local/wormbase/acedb/wormbase<br />
acedb><br />
// Found 204526 objects<br />
// 204526 Active Objects<br />
acedb> // 204526 objects dumped<br />
// 204526 Active Objects<br />
acedb><br />
// Found 186343 objects<br />
// 186343 Active Objects<br />
acedb> // 186343 objects dumped<br />
// 186343 Active Objects<br />
acedb><br />
// Found 188862 objects<br />
// 188862 Active Objects<br />
acedb> // 188862 objects dumped<br />
// 188862 Active Objects<br />
acedb><br />
// Found 221196 objects<br />
// 221196 Active Objects<br />
acedb> // 221196 objects dumped<br />
// 221196 Active Objects<br />
acedb> // ERROR - Failed to open for reading: /home/jbaran/src/website-intermine/acedb-dev/acedb/species.ace (system error 2 - No such file or directory)<br />
// Sorry, I could not open file /home/jbaran/src/website-intermine/acedb-dev/acedb/species.ace<br />
// 221196 Active Objects<br />
acedb> // 221196 objects dumped<br />
// 221196 Active Objects<br />
acedb> // 221196 Active Objects<br />
acedb><br />
// A bientot<br />
</pre><br />
<br />
===== Pre-Processing =====<br />
<br />
Host: WormMine dev server (206.108.125.174)<br />
<br />
User: intermine<br />
<br />
Path: <code>/nfs/wormbase/data/acedmp</code><br />
<br />
Commands:<br />
<br />
<pre><br />
mkdir WS240<br />
cd WS240<br />
scp jbaran@dev.wormbase.org:/mnt/ephemeral0/acedb_dump_ws240/* .<br />
cd /home/intermine/website-intermine/acedb-dev/intermine/redeployment<br />
# Set "release = WS240" in update.properties<br />
ant<br />
</pre><br />
<br />
Output: ''too long to show here''<br />
<br />
===== InterMine Build =====<br />
<br />
Host: WormMine dev server (206.108.125.174)<br />
<br />
User: intermine<br />
<br />
Path: <code>/home/intermine/website-intermine</code><br />
<br />
Command: <code>./scripts/build_intermine.sh WS240</code><br />
<br />
Output (stdout, stderr not shown):<br />
<br />
<pre><br />
USING RELEASE: WS240<br />
DATABASE NAME: wormmine_ws240<br />
Updating ~/.intermine/wormmine.properties...<br />
Updating project.xml...<br />
Building the InterMine database...<br />
<br />
action name time in seconds<br />
-------------------------------------------------------------<br />
entrez-organism 130<br />
create-chromosome-locations-and-lengths 1075<br />
do-sources 51<br />
create-search-index 3747<br />
summarise-objectstore 740<br />
create-autocomplete-index 41<br />
create-attribute-indexes 191<br />
transfer-sequences 209663<br />
final-dump 1246<br />
<br />
total 216884<br />
</pre><br />
<br />
<span style="color: red">'''Quick fix for resolving missing organisms.xml file:'''</span><br />
<br />
<pre><br />
cd /nfs/wormbase/data/intermine/datadir<br />
mkdir entrez-organism<br />
cp /home/intermine/organisms.xml entrez-organism<br />
</pre><br />
<br />
===== Deployment =====<br />
<br />
TBD<br />
<br />
=== WS239 ===<br />
<br />
==== Build ====<br />
<br />
Host: WormMine dev server (206.108.125.174)<br />
<br />
Path: <code>/home/jbaran/src/website-intermine/acedb-dev/intermine/wormmine</code><br />
<br />
Command: <code>../bio/scripts/project_build -l -v localhost joachim_ws239_2</code><br />
<br />
Summary:<br />
<br />
<pre><br />
action name time in seconds<br />
-------------------------------------------------------------<br />
entrez-organism 95<br />
create-chromosome-locations-and-lengths 708<br />
do-sources 25<br />
create-search-index 983<br />
summarise-objectstore 245<br />
create-autocomplete-index 28<br />
create-attribute-indexes 95<br />
transfer-sequences 248429<br />
final-dump 697<br />
<br />
total 251305<br />
</pre><br />
<br />
==== Deployment ====<br />
<br />
Host: WormMine production server (206.108.125.166)<br />
<br />
Path: <code>/nfs/wormbase/archive/jbaran/WS239-2</code><br />
<br />
Commands:<br />
<br />
<pre><br />
dropdb -U intermine joachim-ws239-2<br />
createdb -U intermine -E SQL_ASCII joachim-ws239-2<br />
pg_restore -U intermine_admin -d joachim-ws239-2 joachim_ws239_2.final<br />
</pre><br />
<br />
Required Disk Space:<br />
<br />
1.3G joachim_ws239_2.final + 17G PostgreSQL DB<br />
<br />
[[Category: Architecture (Web Dev)]]</div>Acabunochttps://wiki.wormbase.org/index.php?title=Website:WormMine_Builds&diff=24442Website:WormMine Builds2014-08-12T15:33:00Z<p>Acabunoc: </p>
<hr />
<div>=== WS244 ===<br />
<br />
==== Build ====<br />
<br />
===== AceDB Dump =====<br />
<br />
Host: dev.wormbase.org<br />
<br />
User: intermine<br />
<br />
Path: <code> /home/intermine</code><br />
<br />
Command: <code>./website-intermine/scripts/dump_ace.sh /mnt/ephemeral0/acedb_dump_ws244</code><br />
<br />
Note: DO NOT add a trailing backslash after the path<br />
<br />
Output<br />
<br />
<pre><br />
./website-intermine/scripts/dump_ace.sh /mnt/ephemeral0/acedb_dump_ws244<br />
Did not specify AceDB dir in $ACEDB. Searching for tace...<br />
ACEDB set to: /usr/local/wormbase/acedb/wormbase<br />
Transcript<br />
<br />
... done.<br />
Variation<br />
... done.<br />
Phenotype<br />
... done.<br />
Expr_pattern<br />
... done.<br />
Expression_cluster<br />
... done.<br />
Anatomy_term<br />
... done.<br />
Expr_cluster<br />
... done.<br />
Life_stage<br />
... done.<br />
RNAi<br />
... done.<br />
<br />
**** Program tace, compiled on: May 14 2010 09:21:02 ****<br />
**** Using ACEDB 4.9.52, compiled on: May 14 2010 09:20:07 ****<br />
<br />
Code by: Jean Thierry-Mieg (CNRS, France) mieg@crbm.cnrs-mop.fr<br />
Richard Durbin (Sanger Centre, UK) rd@sanger.ac.uk<br />
Ed Griffiths (Sanger Centre, UK) edgrif@sanger.ac.uk<br />
<br />
You may redistribute this program and database subject to the<br />
conditions in the accompanying copyright file. Anyone interested in<br />
maintaining an up-to-date version should contact one of the authors<br />
at the above email addresses.<br />
<br />
// Database directory: /usr/local/wormbase/acedb/wormbase<br />
// Session 594 is readlocked by acabunoc since 2014-08-11_18:29:04 using tace (process 31767 on machine dev.wormbase.org)<br />
// Session 594 is readlocked by getLoginFailed since 2014-08-11_19:28:09 using tace (process 672 on machine dev.wormbase.org)<br />
acedb> <br />
// Found 223435 objects<br />
// 223435 Active Objects<br />
acedb> // 223435 objects dumped<br />
// 223435 Active Objects<br />
acedb> <br />
// Found 199169 objects<br />
// 199169 Active Objects<br />
acedb> // 199169 objects dumped<br />
// 199169 Active Objects<br />
acedb> <br />
// Found 201722 objects<br />
// 201722 Active Objects<br />
acedb> // 201722 objects dumped<br />
// 201722 Active Objects<br />
acedb> <br />
// Found 239936 objects<br />
// 239936 Active Objects<br />
acedb> // 239936 objects dumped<br />
// 239936 Active Objects<br />
acedb> // ERROR - Failed to open for reading: /home/intermine/website-intermine/acedb-dev/acedb/species.ace (system error 2 - No such file or directory)<br />
// Sorry, I could not open file /home/intermine/website-intermine/acedb-dev/acedb/species.ace<br />
// 239936 Active Objects<br />
acedb> // 239936 objects dumped<br />
// 239936 Active Objects<br />
acedb> // 239936 Active Objects<br />
acedb> <br />
// A bientot<br />
</pre><br />
<br />
<br />
<br />
===== Pre-Processing =====<br />
<br />
Host: WormMine dev server (206.108.125.174)<br />
<br />
User: intermine<br />
<br />
Path: <code>/nfs/wormbase/data/acedmp</code><br />
<br />
Commands:<br />
<br />
<pre><br />
mkdir WS244<br />
cd WS244<br />
scp acabunoc@dev.wormbase.org:/mnt/ephemeral0/acedb_dump_ws244/* .<br />
cd /home/intermine/website-intermine/acedb-dev/intermine/redeployment<br />
# Set "release = WS244" in update.properties<br />
ant<br />
</pre><br />
<br />
Build failed with error:<br />
<code>/nfs/wormbase/data/intermine/redeployment/build.xml:68: Property 'bpid-c_sp11' is not defined.</code><br />
<br />
Fixed by adding line to <code>assemblies.properties</code>:<br />
<code>bpid-c_sp11 = PRJNA53597</code><br />
<br />
<br />
<br />
=== WS240 ===<br />
<br />
==== Build ====<br />
<br />
===== ACeDB Dump =====<br />
<br />
Host: Website dev server<br />
<br />
User: intermine<br />
<br />
Path: <code>/home/intermine</code><br />
<br />
Command: <code>./website-intermine/scripts/dump_ace.sh /mnt/ephemeral0/acedb_dump_ws240</code><br />
<br />
Output:<br />
<br />
<pre><br />
Did not specify AceDB dir in $ACEDB. Searching for tace...<br />
ACEDB set to: /usr/local/wormbase/acedb/wormbase<br />
Transcript<br />
... done.<br />
Variation<br />
... done.<br />
Phenotype<br />
... done.<br />
Expr_pattern<br />
... done.<br />
Expression_cluster<br />
... done.<br />
Anatomy_term<br />
... done.<br />
Expr_cluster<br />
... done.<br />
Life_stage<br />
... done.<br />
RNAi<br />
... done.<br />
<br />
**** Program tace, compiled on: May 14 2010 09:21:02 ****<br />
**** Using ACEDB 4.9.52, compiled on: May 14 2010 09:20:07 ****<br />
<br />
Code by: Jean Thierry-Mieg (CNRS, France) mieg@crbm.cnrs-mop.fr<br />
Richard Durbin (Sanger Centre, UK) rd@sanger.ac.uk<br />
Ed Griffiths (Sanger Centre, UK) edgrif@sanger.ac.uk<br />
<br />
You may redistribute this program and database subject to the<br />
conditions in the accompanying copyright file. Anyone interested in<br />
maintaining an up-to-date version should contact one of the authors<br />
at the above email addresses.<br />
<br />
// Database directory: /usr/local/wormbase/acedb/wormbase<br />
acedb><br />
// Found 204526 objects<br />
// 204526 Active Objects<br />
acedb> // 204526 objects dumped<br />
// 204526 Active Objects<br />
acedb><br />
// Found 186343 objects<br />
// 186343 Active Objects<br />
acedb> // 186343 objects dumped<br />
// 186343 Active Objects<br />
acedb><br />
// Found 188862 objects<br />
// 188862 Active Objects<br />
acedb> // 188862 objects dumped<br />
// 188862 Active Objects<br />
acedb><br />
// Found 221196 objects<br />
// 221196 Active Objects<br />
acedb> // 221196 objects dumped<br />
// 221196 Active Objects<br />
acedb> // ERROR - Failed to open for reading: /home/jbaran/src/website-intermine/acedb-dev/acedb/species.ace (system error 2 - No such file or directory)<br />
// Sorry, I could not open file /home/jbaran/src/website-intermine/acedb-dev/acedb/species.ace<br />
// 221196 Active Objects<br />
acedb> // 221196 objects dumped<br />
// 221196 Active Objects<br />
acedb> // 221196 Active Objects<br />
acedb><br />
// A bientot<br />
</pre><br />
<br />
===== Pre-Processing =====<br />
<br />
Host: WormMine dev server (206.108.125.174)<br />
<br />
User: intermine<br />
<br />
Path: <code>/nfs/wormbase/data/acedmp</code><br />
<br />
Commands:<br />
<br />
<pre><br />
mkdir WS240<br />
cd WS240<br />
scp jbaran@dev.wormbase.org:/mnt/ephemeral0/acedb_dump_ws240/* .<br />
cd /home/intermine/website-intermine/acedb-dev/intermine/redeployment<br />
# Set "release = WS240" in update.properties<br />
ant<br />
</pre><br />
<br />
Output: ''too long to show here''<br />
<br />
===== InterMine Build =====<br />
<br />
Host: WormMine dev server (206.108.125.174)<br />
<br />
User: intermine<br />
<br />
Path: <code>/home/intermine/website-intermine</code><br />
<br />
Command: <code>./scripts/build_intermine.sh WS240</code><br />
<br />
Output (stdout, stderr not shown):<br />
<br />
<pre><br />
USING RELEASE: WS240<br />
DATABASE NAME: wormmine_ws240<br />
Updating ~/.intermine/wormmine.properties...<br />
Updating project.xml...<br />
Building the InterMine database...<br />
<br />
action name time in seconds<br />
-------------------------------------------------------------<br />
entrez-organism 130<br />
create-chromosome-locations-and-lengths 1075<br />
do-sources 51<br />
create-search-index 3747<br />
summarise-objectstore 740<br />
create-autocomplete-index 41<br />
create-attribute-indexes 191<br />
transfer-sequences 209663<br />
final-dump 1246<br />
<br />
total 216884<br />
</pre><br />
<br />
<span style="color: red">'''Quick fix for resolving missing organisms.xml file:'''</span><br />
<br />
<pre><br />
cd /nfs/wormbase/data/intermine/datadir<br />
mkdir entrez-organism<br />
cp /home/intermine/organisms.xml entrez-organism<br />
</pre><br />
<br />
===== Deployment =====<br />
<br />
TBD<br />
<br />
=== WS239 ===<br />
<br />
==== Build ====<br />
<br />
Host: WormMine dev server (206.108.125.174)<br />
<br />
Path: <code>/home/jbaran/src/website-intermine/acedb-dev/intermine/wormmine</code><br />
<br />
Command: <code>../bio/scripts/project_build -l -v localhost joachim_ws239_2</code><br />
<br />
Summary:<br />
<br />
<pre><br />
action name time in seconds<br />
-------------------------------------------------------------<br />
entrez-organism 95<br />
create-chromosome-locations-and-lengths 708<br />
do-sources 25<br />
create-search-index 983<br />
summarise-objectstore 245<br />
create-autocomplete-index 28<br />
create-attribute-indexes 95<br />
transfer-sequences 248429<br />
final-dump 697<br />
<br />
total 251305<br />
</pre><br />
<br />
==== Deployment ====<br />
<br />
Host: WormMine production server (206.108.125.166)<br />
<br />
Path: <code>/nfs/wormbase/archive/jbaran/WS239-2</code><br />
<br />
Commands:<br />
<br />
<pre><br />
dropdb -U intermine joachim-ws239-2<br />
createdb -U intermine -E SQL_ASCII joachim-ws239-2<br />
pg_restore -U intermine_admin -d joachim-ws239-2 joachim_ws239_2.final<br />
</pre><br />
<br />
Required Disk Space:<br />
<br />
1.3G joachim_ws239_2.final + 17G PostgreSQL DB<br />
<br />
[[Category: Architecture (Web Dev)]]</div>Acabunochttps://wiki.wormbase.org/index.php?title=Website:WormMine_Builds&diff=24439Website:WormMine Builds2014-08-12T14:49:32Z<p>Acabunoc: </p>
<hr />
<div>=== WS244 ===<br />
<br />
==== Build ====<br />
<br />
===== AceDB Dump =====<br />
<br />
Host: dev.wormbase.org<br />
<br />
User: intermine<br />
<br />
Path: <code> /home/intermine</code><br />
<br />
Command: <code>./website-intermine/scripts/dump_ace.sh /mnt/ephemeral0/acedb_dump_ws244</code><br />
<br />
Note: DO NOT add a trailing backslash after the path<br />
<br />
Output<br />
<br />
<pre><br />
./website-intermine/scripts/dump_ace.sh /mnt/ephemeral0/acedb_dump_ws244<br />
Did not specify AceDB dir in $ACEDB. Searching for tace...<br />
ACEDB set to: /usr/local/wormbase/acedb/wormbase<br />
Transcript<br />
<br />
... done.<br />
Variation<br />
... done.<br />
Phenotype<br />
... done.<br />
Expr_pattern<br />
... done.<br />
Expression_cluster<br />
... done.<br />
Anatomy_term<br />
... done.<br />
Expr_cluster<br />
... done.<br />
Life_stage<br />
... done.<br />
RNAi<br />
... done.<br />
<br />
**** Program tace, compiled on: May 14 2010 09:21:02 ****<br />
**** Using ACEDB 4.9.52, compiled on: May 14 2010 09:20:07 ****<br />
<br />
Code by: Jean Thierry-Mieg (CNRS, France) mieg@crbm.cnrs-mop.fr<br />
Richard Durbin (Sanger Centre, UK) rd@sanger.ac.uk<br />
Ed Griffiths (Sanger Centre, UK) edgrif@sanger.ac.uk<br />
<br />
You may redistribute this program and database subject to the<br />
conditions in the accompanying copyright file. Anyone interested in<br />
maintaining an up-to-date version should contact one of the authors<br />
at the above email addresses.<br />
<br />
// Database directory: /usr/local/wormbase/acedb/wormbase<br />
// Session 594 is readlocked by acabunoc since 2014-08-11_18:29:04 using tace (process 31767 on machine dev.wormbase.org)<br />
// Session 594 is readlocked by getLoginFailed since 2014-08-11_19:28:09 using tace (process 672 on machine dev.wormbase.org)<br />
acedb> <br />
// Found 223435 objects<br />
// 223435 Active Objects<br />
acedb> // 223435 objects dumped<br />
// 223435 Active Objects<br />
acedb> <br />
// Found 199169 objects<br />
// 199169 Active Objects<br />
acedb> // 199169 objects dumped<br />
// 199169 Active Objects<br />
acedb> <br />
// Found 201722 objects<br />
// 201722 Active Objects<br />
acedb> // 201722 objects dumped<br />
// 201722 Active Objects<br />
acedb> <br />
// Found 239936 objects<br />
// 239936 Active Objects<br />
acedb> // 239936 objects dumped<br />
// 239936 Active Objects<br />
acedb> // ERROR - Failed to open for reading: /home/intermine/website-intermine/acedb-dev/acedb/species.ace (system error 2 - No such file or directory)<br />
// Sorry, I could not open file /home/intermine/website-intermine/acedb-dev/acedb/species.ace<br />
// 239936 Active Objects<br />
acedb> // 239936 objects dumped<br />
// 239936 Active Objects<br />
acedb> // 239936 Active Objects<br />
acedb> <br />
// A bientot<br />
</pre><br />
<br />
<br />
<br />
===== Pre-Processing =====<br />
<br />
Host: WormMine dev server (206.108.125.174)<br />
<br />
User: intermine<br />
<br />
Path: <code>/nfs/wormbase/data/acedmp</code><br />
<br />
Commands:<br />
<br />
<pre><br />
mkdir WS244<br />
cd WS244<br />
scp acabunoc@dev.wormbase.org:/mnt/ephemeral0/acedb_dump_ws244/* .<br />
cd /home/intermine/website-intermine/acedb-dev/intermine/redeployment<br />
# Set "release = WS244" in update.properties<br />
ant<br />
</pre><br />
<br />
Output: ''too long to show here''<br />
<br />
<br />
<br />
=== WS240 ===<br />
<br />
==== Build ====<br />
<br />
===== ACeDB Dump =====<br />
<br />
Host: Website dev server<br />
<br />
User: intermine<br />
<br />
Path: <code>/home/intermine</code><br />
<br />
Command: <code>./website-intermine/scripts/dump_ace.sh /mnt/ephemeral0/acedb_dump_ws240</code><br />
<br />
Output:<br />
<br />
<pre><br />
Did not specify AceDB dir in $ACEDB. Searching for tace...<br />
ACEDB set to: /usr/local/wormbase/acedb/wormbase<br />
Transcript<br />
... done.<br />
Variation<br />
... done.<br />
Phenotype<br />
... done.<br />
Expr_pattern<br />
... done.<br />
Expression_cluster<br />
... done.<br />
Anatomy_term<br />
... done.<br />
Expr_cluster<br />
... done.<br />
Life_stage<br />
... done.<br />
RNAi<br />
... done.<br />
<br />
**** Program tace, compiled on: May 14 2010 09:21:02 ****<br />
**** Using ACEDB 4.9.52, compiled on: May 14 2010 09:20:07 ****<br />
<br />
Code by: Jean Thierry-Mieg (CNRS, France) mieg@crbm.cnrs-mop.fr<br />
Richard Durbin (Sanger Centre, UK) rd@sanger.ac.uk<br />
Ed Griffiths (Sanger Centre, UK) edgrif@sanger.ac.uk<br />
<br />
You may redistribute this program and database subject to the<br />
conditions in the accompanying copyright file. Anyone interested in<br />
maintaining an up-to-date version should contact one of the authors<br />
at the above email addresses.<br />
<br />
// Database directory: /usr/local/wormbase/acedb/wormbase<br />
acedb><br />
// Found 204526 objects<br />
// 204526 Active Objects<br />
acedb> // 204526 objects dumped<br />
// 204526 Active Objects<br />
acedb><br />
// Found 186343 objects<br />
// 186343 Active Objects<br />
acedb> // 186343 objects dumped<br />
// 186343 Active Objects<br />
acedb><br />
// Found 188862 objects<br />
// 188862 Active Objects<br />
acedb> // 188862 objects dumped<br />
// 188862 Active Objects<br />
acedb><br />
// Found 221196 objects<br />
// 221196 Active Objects<br />
acedb> // 221196 objects dumped<br />
// 221196 Active Objects<br />
acedb> // ERROR - Failed to open for reading: /home/jbaran/src/website-intermine/acedb-dev/acedb/species.ace (system error 2 - No such file or directory)<br />
// Sorry, I could not open file /home/jbaran/src/website-intermine/acedb-dev/acedb/species.ace<br />
// 221196 Active Objects<br />
acedb> // 221196 objects dumped<br />
// 221196 Active Objects<br />
acedb> // 221196 Active Objects<br />
acedb><br />
// A bientot<br />
</pre><br />
<br />
===== Pre-Processing =====<br />
<br />
Host: WormMine dev server (206.108.125.174)<br />
<br />
User: intermine<br />
<br />
Path: <code>/nfs/wormbase/data/acedmp</code><br />
<br />
Commands:<br />
<br />
<pre><br />
mkdir WS240<br />
cd WS240<br />
scp jbaran@dev.wormbase.org:/mnt/ephemeral0/acedb_dump_ws240/* .<br />
cd /home/intermine/website-intermine/acedb-dev/intermine/redeployment<br />
# Set "release = WS240" in update.properties<br />
ant<br />
</pre><br />
<br />
Output: ''too long to show here''<br />
<br />
===== InterMine Build =====<br />
<br />
Host: WormMine dev server (206.108.125.174)<br />
<br />
User: intermine<br />
<br />
Path: <code>/home/intermine/website-intermine</code><br />
<br />
Command: <code>./scripts/build_intermine.sh WS240</code><br />
<br />
Output (stdout, stderr not shown):<br />
<br />
<pre><br />
USING RELEASE: WS240<br />
DATABASE NAME: wormmine_ws240<br />
Updating ~/.intermine/wormmine.properties...<br />
Updating project.xml...<br />
Building the InterMine database...<br />
<br />
action name time in seconds<br />
-------------------------------------------------------------<br />
entrez-organism 130<br />
create-chromosome-locations-and-lengths 1075<br />
do-sources 51<br />
create-search-index 3747<br />
summarise-objectstore 740<br />
create-autocomplete-index 41<br />
create-attribute-indexes 191<br />
transfer-sequences 209663<br />
final-dump 1246<br />
<br />
total 216884<br />
</pre><br />
<br />
<span style="color: red">'''Quick fix for resolving missing organisms.xml file:'''</span><br />
<br />
<pre><br />
cd /nfs/wormbase/data/intermine/datadir<br />
mkdir entrez-organism<br />
cp /home/intermine/organisms.xml entrez-organism<br />
</pre><br />
<br />
===== Deployment =====<br />
<br />
TBD<br />
<br />
=== WS239 ===<br />
<br />
==== Build ====<br />
<br />
Host: WormMine dev server (206.108.125.174)<br />
<br />
Path: <code>/home/jbaran/src/website-intermine/acedb-dev/intermine/wormmine</code><br />
<br />
Command: <code>../bio/scripts/project_build -l -v localhost joachim_ws239_2</code><br />
<br />
Summary:<br />
<br />
<pre><br />
action name time in seconds<br />
-------------------------------------------------------------<br />
entrez-organism 95<br />
create-chromosome-locations-and-lengths 708<br />
do-sources 25<br />
create-search-index 983<br />
summarise-objectstore 245<br />
create-autocomplete-index 28<br />
create-attribute-indexes 95<br />
transfer-sequences 248429<br />
final-dump 697<br />
<br />
total 251305<br />
</pre><br />
<br />
==== Deployment ====<br />
<br />
Host: WormMine production server (206.108.125.166)<br />
<br />
Path: <code>/nfs/wormbase/archive/jbaran/WS239-2</code><br />
<br />
Commands:<br />
<br />
<pre><br />
dropdb -U intermine joachim-ws239-2<br />
createdb -U intermine -E SQL_ASCII joachim-ws239-2<br />
pg_restore -U intermine_admin -d joachim-ws239-2 joachim_ws239_2.final<br />
</pre><br />
<br />
Required Disk Space:<br />
<br />
1.3G joachim_ws239_2.final + 17G PostgreSQL DB<br />
<br />
[[Category: Architecture (Web Dev)]]</div>Acabunochttps://wiki.wormbase.org/index.php?title=Website:WormMine_Builds&diff=24438Website:WormMine Builds2014-08-12T14:49:10Z<p>Acabunoc: </p>
<hr />
<div>=== WS244 ===<br />
<br />
==== Build ====<br />
<br />
===== AceDB Dump =====<br />
<br />
Host: dev.wormbase.org<br />
User: intermine<br />
Path: <code> /home/intermine</code><br />
Command: <code>./website-intermine/scripts/dump_ace.sh /mnt/ephemeral0/acedb_dump_ws244</code><br />
Note: DO NOT add a trailing backslash after the path<br />
<br />
Output<br />
<br />
<pre><br />
./website-intermine/scripts/dump_ace.sh /mnt/ephemeral0/acedb_dump_ws244<br />
Did not specify AceDB dir in $ACEDB. Searching for tace...<br />
ACEDB set to: /usr/local/wormbase/acedb/wormbase<br />
Transcript<br />
<br />
... done.<br />
Variation<br />
... done.<br />
Phenotype<br />
... done.<br />
Expr_pattern<br />
... done.<br />
Expression_cluster<br />
... done.<br />
Anatomy_term<br />
... done.<br />
Expr_cluster<br />
... done.<br />
Life_stage<br />
... done.<br />
RNAi<br />
... done.<br />
<br />
**** Program tace, compiled on: May 14 2010 09:21:02 ****<br />
**** Using ACEDB 4.9.52, compiled on: May 14 2010 09:20:07 ****<br />
<br />
Code by: Jean Thierry-Mieg (CNRS, France) mieg@crbm.cnrs-mop.fr<br />
Richard Durbin (Sanger Centre, UK) rd@sanger.ac.uk<br />
Ed Griffiths (Sanger Centre, UK) edgrif@sanger.ac.uk<br />
<br />
You may redistribute this program and database subject to the<br />
conditions in the accompanying copyright file. Anyone interested in<br />
maintaining an up-to-date version should contact one of the authors<br />
at the above email addresses.<br />
<br />
// Database directory: /usr/local/wormbase/acedb/wormbase<br />
// Session 594 is readlocked by acabunoc since 2014-08-11_18:29:04 using tace (process 31767 on machine dev.wormbase.org)<br />
// Session 594 is readlocked by getLoginFailed since 2014-08-11_19:28:09 using tace (process 672 on machine dev.wormbase.org)<br />
acedb> <br />
// Found 223435 objects<br />
// 223435 Active Objects<br />
acedb> // 223435 objects dumped<br />
// 223435 Active Objects<br />
acedb> <br />
// Found 199169 objects<br />
// 199169 Active Objects<br />
acedb> // 199169 objects dumped<br />
// 199169 Active Objects<br />
acedb> <br />
// Found 201722 objects<br />
// 201722 Active Objects<br />
acedb> // 201722 objects dumped<br />
// 201722 Active Objects<br />
acedb> <br />
// Found 239936 objects<br />
// 239936 Active Objects<br />
acedb> // 239936 objects dumped<br />
// 239936 Active Objects<br />
acedb> // ERROR - Failed to open for reading: /home/intermine/website-intermine/acedb-dev/acedb/species.ace (system error 2 - No such file or directory)<br />
// Sorry, I could not open file /home/intermine/website-intermine/acedb-dev/acedb/species.ace<br />
// 239936 Active Objects<br />
acedb> // 239936 objects dumped<br />
// 239936 Active Objects<br />
acedb> // 239936 Active Objects<br />
acedb> <br />
// A bientot<br />
</pre><br />
<br />
<br />
<br />
===== Pre-Processing =====<br />
<br />
Host: WormMine dev server (206.108.125.174)<br />
<br />
User: intermine<br />
<br />
Path: <code>/nfs/wormbase/data/acedmp</code><br />
<br />
Commands:<br />
<br />
<pre><br />
mkdir WS244<br />
cd WS244<br />
scp acabunoc@dev.wormbase.org:/mnt/ephemeral0/acedb_dump_ws244/* .<br />
cd /home/intermine/website-intermine/acedb-dev/intermine/redeployment<br />
# Set "release = WS244" in update.properties<br />
ant<br />
</pre><br />
<br />
Output: ''too long to show here''<br />
<br />
<br />
<br />
=== WS240 ===<br />
<br />
==== Build ====<br />
<br />
===== ACeDB Dump =====<br />
<br />
Host: Website dev server<br />
<br />
User: intermine<br />
<br />
Path: <code>/home/intermine</code><br />
<br />
Command: <code>./website-intermine/scripts/dump_ace.sh /mnt/ephemeral0/acedb_dump_ws240</code><br />
<br />
Output:<br />
<br />
<pre><br />
Did not specify AceDB dir in $ACEDB. Searching for tace...<br />
ACEDB set to: /usr/local/wormbase/acedb/wormbase<br />
Transcript<br />
... done.<br />
Variation<br />
... done.<br />
Phenotype<br />
... done.<br />
Expr_pattern<br />
... done.<br />
Expression_cluster<br />
... done.<br />
Anatomy_term<br />
... done.<br />
Expr_cluster<br />
... done.<br />
Life_stage<br />
... done.<br />
RNAi<br />
... done.<br />
<br />
**** Program tace, compiled on: May 14 2010 09:21:02 ****<br />
**** Using ACEDB 4.9.52, compiled on: May 14 2010 09:20:07 ****<br />
<br />
Code by: Jean Thierry-Mieg (CNRS, France) mieg@crbm.cnrs-mop.fr<br />
Richard Durbin (Sanger Centre, UK) rd@sanger.ac.uk<br />
Ed Griffiths (Sanger Centre, UK) edgrif@sanger.ac.uk<br />
<br />
You may redistribute this program and database subject to the<br />
conditions in the accompanying copyright file. Anyone interested in<br />
maintaining an up-to-date version should contact one of the authors<br />
at the above email addresses.<br />
<br />
// Database directory: /usr/local/wormbase/acedb/wormbase<br />
acedb><br />
// Found 204526 objects<br />
// 204526 Active Objects<br />
acedb> // 204526 objects dumped<br />
// 204526 Active Objects<br />
acedb><br />
// Found 186343 objects<br />
// 186343 Active Objects<br />
acedb> // 186343 objects dumped<br />
// 186343 Active Objects<br />
acedb><br />
// Found 188862 objects<br />
// 188862 Active Objects<br />
acedb> // 188862 objects dumped<br />
// 188862 Active Objects<br />
acedb><br />
// Found 221196 objects<br />
// 221196 Active Objects<br />
acedb> // 221196 objects dumped<br />
// 221196 Active Objects<br />
acedb> // ERROR - Failed to open for reading: /home/jbaran/src/website-intermine/acedb-dev/acedb/species.ace (system error 2 - No such file or directory)<br />
// Sorry, I could not open file /home/jbaran/src/website-intermine/acedb-dev/acedb/species.ace<br />
// 221196 Active Objects<br />
acedb> // 221196 objects dumped<br />
// 221196 Active Objects<br />
acedb> // 221196 Active Objects<br />
acedb><br />
// A bientot<br />
</pre><br />
<br />
===== Pre-Processing =====<br />
<br />
Host: WormMine dev server (206.108.125.174)<br />
<br />
User: intermine<br />
<br />
Path: <code>/nfs/wormbase/data/acedmp</code><br />
<br />
Commands:<br />
<br />
<pre><br />
mkdir WS240<br />
cd WS240<br />
scp jbaran@dev.wormbase.org:/mnt/ephemeral0/acedb_dump_ws240/* .<br />
cd /home/intermine/website-intermine/acedb-dev/intermine/redeployment<br />
# Set "release = WS240" in update.properties<br />
ant<br />
</pre><br />
<br />
Output: ''too long to show here''<br />
<br />
===== InterMine Build =====<br />
<br />
Host: WormMine dev server (206.108.125.174)<br />
<br />
User: intermine<br />
<br />
Path: <code>/home/intermine/website-intermine</code><br />
<br />
Command: <code>./scripts/build_intermine.sh WS240</code><br />
<br />
Output (stdout, stderr not shown):<br />
<br />
<pre><br />
USING RELEASE: WS240<br />
DATABASE NAME: wormmine_ws240<br />
Updating ~/.intermine/wormmine.properties...<br />
Updating project.xml...<br />
Building the InterMine database...<br />
<br />
action name time in seconds<br />
-------------------------------------------------------------<br />
entrez-organism 130<br />
create-chromosome-locations-and-lengths 1075<br />
do-sources 51<br />
create-search-index 3747<br />
summarise-objectstore 740<br />
create-autocomplete-index 41<br />
create-attribute-indexes 191<br />
transfer-sequences 209663<br />
final-dump 1246<br />
<br />
total 216884<br />
</pre><br />
<br />
<span style="color: red">'''Quick fix for resolving missing organisms.xml file:'''</span><br />
<br />
<pre><br />
cd /nfs/wormbase/data/intermine/datadir<br />
mkdir entrez-organism<br />
cp /home/intermine/organisms.xml entrez-organism<br />
</pre><br />
<br />
===== Deployment =====<br />
<br />
TBD<br />
<br />
=== WS239 ===<br />
<br />
==== Build ====<br />
<br />
Host: WormMine dev server (206.108.125.174)<br />
<br />
Path: <code>/home/jbaran/src/website-intermine/acedb-dev/intermine/wormmine</code><br />
<br />
Command: <code>../bio/scripts/project_build -l -v localhost joachim_ws239_2</code><br />
<br />
Summary:<br />
<br />
<pre><br />
action name time in seconds<br />
-------------------------------------------------------------<br />
entrez-organism 95<br />
create-chromosome-locations-and-lengths 708<br />
do-sources 25<br />
create-search-index 983<br />
summarise-objectstore 245<br />
create-autocomplete-index 28<br />
create-attribute-indexes 95<br />
transfer-sequences 248429<br />
final-dump 697<br />
<br />
total 251305<br />
</pre><br />
<br />
==== Deployment ====<br />
<br />
Host: WormMine production server (206.108.125.166)<br />
<br />
Path: <code>/nfs/wormbase/archive/jbaran/WS239-2</code><br />
<br />
Commands:<br />
<br />
<pre><br />
dropdb -U intermine joachim-ws239-2<br />
createdb -U intermine -E SQL_ASCII joachim-ws239-2<br />
pg_restore -U intermine_admin -d joachim-ws239-2 joachim_ws239_2.final<br />
</pre><br />
<br />
Required Disk Space:<br />
<br />
1.3G joachim_ws239_2.final + 17G PostgreSQL DB<br />
<br />
[[Category: Architecture (Web Dev)]]</div>Acabunochttps://wiki.wormbase.org/index.php?title=Website:WormMine_Builds&diff=24436Website:WormMine Builds2014-08-12T14:47:23Z<p>Acabunoc: </p>
<hr />
<div>=== WS244 ===<br />
<br />
==== Build ====<br />
<br />
===== AceDB Dump =====<br />
<br />
Host: dev.wormbase.org<br />
User: intermine<br />
Path: <code> /home/intermine</code><br />
Command: <code>./website-intermine/scripts/dump_ace.sh /mnt/ephemeral0/acedb_dump_ws244</code><br />
Note: DO NOT add a trailing backslash after the path<br />
<br />
Output<br />
<br />
<pre><br />
./website-intermine/scripts/dump_ace.sh /mnt/ephemeral0/acedb_dump_ws244<br />
Did not specify AceDB dir in $ACEDB. Searching for tace...<br />
ACEDB set to: /usr/local/wormbase/acedb/wormbase<br />
Transcript<br />
<br />
... done.<br />
Variation<br />
... done.<br />
Phenotype<br />
... done.<br />
Expr_pattern<br />
... done.<br />
Expression_cluster<br />
... done.<br />
Anatomy_term<br />
... done.<br />
Expr_cluster<br />
... done.<br />
Life_stage<br />
... done.<br />
RNAi<br />
... done.<br />
<br />
**** Program tace, compiled on: May 14 2010 09:21:02 ****<br />
**** Using ACEDB 4.9.52, compiled on: May 14 2010 09:20:07 ****<br />
<br />
Code by: Jean Thierry-Mieg (CNRS, France) mieg@crbm.cnrs-mop.fr<br />
Richard Durbin (Sanger Centre, UK) rd@sanger.ac.uk<br />
Ed Griffiths (Sanger Centre, UK) edgrif@sanger.ac.uk<br />
<br />
You may redistribute this program and database subject to the<br />
conditions in the accompanying copyright file. Anyone interested in<br />
maintaining an up-to-date version should contact one of the authors<br />
at the above email addresses.<br />
<br />
// Database directory: /usr/local/wormbase/acedb/wormbase<br />
// Session 594 is readlocked by acabunoc since 2014-08-11_18:29:04 using tace (process 31767 on machine dev.wormbase.org)<br />
// Session 594 is readlocked by getLoginFailed since 2014-08-11_19:28:09 using tace (process 672 on machine dev.wormbase.org)<br />
acedb> <br />
// Found 223435 objects<br />
// 223435 Active Objects<br />
acedb> // 223435 objects dumped<br />
// 223435 Active Objects<br />
acedb> <br />
// Found 199169 objects<br />
// 199169 Active Objects<br />
acedb> // 199169 objects dumped<br />
// 199169 Active Objects<br />
acedb> <br />
// Found 201722 objects<br />
// 201722 Active Objects<br />
acedb> // 201722 objects dumped<br />
// 201722 Active Objects<br />
acedb> <br />
// Found 239936 objects<br />
// 239936 Active Objects<br />
acedb> ^Z<br />
[1]+ Stopped sudo ./website-intermine/scripts/dump_ace.sh /mnt/ephemeral0/acedb_dump_ws244<br />
acabunoc@dev:/home/intermine$ bg<br />
[1]+ sudo ./website-intermine/scripts/dump_ace.sh /mnt/ephemeral0/acedb_dump_ws244 &<br />
acabunoc@dev:/home/intermine$ // 239936 objects dumped<br />
// 239936 Active Objects<br />
acedb> // ERROR - Failed to open for reading: /home/intermine/website-intermine/acedb-dev/acedb/species.ace (system error 2 - No such file or directory)<br />
// Sorry, I could not open file /home/intermine/website-intermine/acedb-dev/acedb/species.ace<br />
// 239936 Active Objects<br />
acedb> // 239936 objects dumped<br />
// 239936 Active Objects<br />
acedb> // 239936 Active Objects<br />
acedb> <br />
// A bientot<br />
</pre><br />
<br />
=== WS240 ===<br />
<br />
==== Build ====<br />
<br />
===== ACeDB Dump =====<br />
<br />
Host: Website dev server<br />
<br />
User: intermine<br />
<br />
Path: <code>/home/intermine</code><br />
<br />
Command: <code>./website-intermine/scripts/dump_ace.sh /mnt/ephemeral0/acedb_dump_ws240</code><br />
<br />
Output:<br />
<br />
<pre><br />
Did not specify AceDB dir in $ACEDB. Searching for tace...<br />
ACEDB set to: /usr/local/wormbase/acedb/wormbase<br />
Transcript<br />
... done.<br />
Variation<br />
... done.<br />
Phenotype<br />
... done.<br />
Expr_pattern<br />
... done.<br />
Expression_cluster<br />
... done.<br />
Anatomy_term<br />
... done.<br />
Expr_cluster<br />
... done.<br />
Life_stage<br />
... done.<br />
RNAi<br />
... done.<br />
<br />
**** Program tace, compiled on: May 14 2010 09:21:02 ****<br />
**** Using ACEDB 4.9.52, compiled on: May 14 2010 09:20:07 ****<br />
<br />
Code by: Jean Thierry-Mieg (CNRS, France) mieg@crbm.cnrs-mop.fr<br />
Richard Durbin (Sanger Centre, UK) rd@sanger.ac.uk<br />
Ed Griffiths (Sanger Centre, UK) edgrif@sanger.ac.uk<br />
<br />
You may redistribute this program and database subject to the<br />
conditions in the accompanying copyright file. Anyone interested in<br />
maintaining an up-to-date version should contact one of the authors<br />
at the above email addresses.<br />
<br />
// Database directory: /usr/local/wormbase/acedb/wormbase<br />
acedb><br />
// Found 204526 objects<br />
// 204526 Active Objects<br />
acedb> // 204526 objects dumped<br />
// 204526 Active Objects<br />
acedb><br />
// Found 186343 objects<br />
// 186343 Active Objects<br />
acedb> // 186343 objects dumped<br />
// 186343 Active Objects<br />
acedb><br />
// Found 188862 objects<br />
// 188862 Active Objects<br />
acedb> // 188862 objects dumped<br />
// 188862 Active Objects<br />
acedb><br />
// Found 221196 objects<br />
// 221196 Active Objects<br />
acedb> // 221196 objects dumped<br />
// 221196 Active Objects<br />
acedb> // ERROR - Failed to open for reading: /home/jbaran/src/website-intermine/acedb-dev/acedb/species.ace (system error 2 - No such file or directory)<br />
// Sorry, I could not open file /home/jbaran/src/website-intermine/acedb-dev/acedb/species.ace<br />
// 221196 Active Objects<br />
acedb> // 221196 objects dumped<br />
// 221196 Active Objects<br />
acedb> // 221196 Active Objects<br />
acedb><br />
// A bientot<br />
</pre><br />
<br />
===== Pre-Processing =====<br />
<br />
Host: WormMine dev server (206.108.125.174)<br />
<br />
User: intermine<br />
<br />
Path: <code>/nfs/wormbase/data/acedmp</code><br />
<br />
Commands:<br />
<br />
<pre><br />
mkdir WS240<br />
cd WS240<br />
scp jbaran@dev.wormbase.org:/mnt/ephemeral0/acedb_dump_ws240/* .<br />
cd /home/intermine/website-intermine/acedb-dev/intermine/redeployment<br />
# Set "release = WS240" in update.properties<br />
ant<br />
</pre><br />
<br />
Output: ''too long to show here''<br />
<br />
===== InterMine Build =====<br />
<br />
Host: WormMine dev server (206.108.125.174)<br />
<br />
User: intermine<br />
<br />
Path: <code>/home/intermine/website-intermine</code><br />
<br />
Command: <code>./scripts/build_intermine.sh WS240</code><br />
<br />
Output (stdout, stderr not shown):<br />
<br />
<pre><br />
USING RELEASE: WS240<br />
DATABASE NAME: wormmine_ws240<br />
Updating ~/.intermine/wormmine.properties...<br />
Updating project.xml...<br />
Building the InterMine database...<br />
<br />
action name time in seconds<br />
-------------------------------------------------------------<br />
entrez-organism 130<br />
create-chromosome-locations-and-lengths 1075<br />
do-sources 51<br />
create-search-index 3747<br />
summarise-objectstore 740<br />
create-autocomplete-index 41<br />
create-attribute-indexes 191<br />
transfer-sequences 209663<br />
final-dump 1246<br />
<br />
total 216884<br />
</pre><br />
<br />
<span style="color: red">'''Quick fix for resolving missing organisms.xml file:'''</span><br />
<br />
<pre><br />
cd /nfs/wormbase/data/intermine/datadir<br />
mkdir entrez-organism<br />
cp /home/intermine/organisms.xml entrez-organism<br />
</pre><br />
<br />
===== Deployment =====<br />
<br />
TBD<br />
<br />
=== WS239 ===<br />
<br />
==== Build ====<br />
<br />
Host: WormMine dev server (206.108.125.174)<br />
<br />
Path: <code>/home/jbaran/src/website-intermine/acedb-dev/intermine/wormmine</code><br />
<br />
Command: <code>../bio/scripts/project_build -l -v localhost joachim_ws239_2</code><br />
<br />
Summary:<br />
<br />
<pre><br />
action name time in seconds<br />
-------------------------------------------------------------<br />
entrez-organism 95<br />
create-chromosome-locations-and-lengths 708<br />
do-sources 25<br />
create-search-index 983<br />
summarise-objectstore 245<br />
create-autocomplete-index 28<br />
create-attribute-indexes 95<br />
transfer-sequences 248429<br />
final-dump 697<br />
<br />
total 251305<br />
</pre><br />
<br />
==== Deployment ====<br />
<br />
Host: WormMine production server (206.108.125.166)<br />
<br />
Path: <code>/nfs/wormbase/archive/jbaran/WS239-2</code><br />
<br />
Commands:<br />
<br />
<pre><br />
dropdb -U intermine joachim-ws239-2<br />
createdb -U intermine -E SQL_ASCII joachim-ws239-2<br />
pg_restore -U intermine_admin -d joachim-ws239-2 joachim_ws239_2.final<br />
</pre><br />
<br />
Required Disk Space:<br />
<br />
1.3G joachim_ws239_2.final + 17G PostgreSQL DB<br />
<br />
[[Category: Architecture (Web Dev)]]</div>Acabunochttps://wiki.wormbase.org/index.php?title=WebDev_2014.08.01-Agenda_and_Minutes&diff=24319WebDev 2014.08.01-Agenda and Minutes2014-08-01T14:50:41Z<p>Acabunoc: </p>
<hr />
<div>= Agenda =<br />
<br />
== Admin ==<br />
Post your July summaries to the Google Drive<br />
<br />
== Development Status WS244 ==<br />
2 weeks from development deadline<br />
<br />
== GBrowse / JBrowse ==<br />
<br />
= MInutes =</div>Acabunochttps://wiki.wormbase.org/index.php?title=WebDev_2014.08.01-Agenda_and_Minutes&diff=24318WebDev 2014.08.01-Agenda and Minutes2014-08-01T14:50:20Z<p>Acabunoc: /* Agenda */</p>
<hr />
<div>= Agenda =<br />
<br />
== Admin ==<br />
Post your July summaries to the Google Drive<br />
<br />
<br />
== Development Status WS244 ==<br />
2 weeks from development deadline<br />
<br />
<br />
== GBrowse / JBrowse ==<br />
<br />
= MInutes =</div>Acabunochttps://wiki.wormbase.org/index.php?title=File:Git_Workflow_-_WormBase4.png&diff=24312File:Git Workflow - WormBase4.png2014-07-29T20:23:06Z<p>Acabunoc: Acabunoc uploaded a new version of &quot;File:Git Workflow - WormBase4.png&quot;</p>
<hr />
<div></div>Acabunochttps://wiki.wormbase.org/index.php?title=File:Git_Workflow_-_WormBase4.png&diff=24311File:Git Workflow - WormBase4.png2014-07-29T20:06:49Z<p>Acabunoc: Acabunoc uploaded a new version of &quot;File:Git Workflow - WormBase4.png&quot;</p>
<hr />
<div></div>Acabunochttps://wiki.wormbase.org/index.php?title=Development_workflow_-_webdev&diff=24310Development workflow - webdev2014-07-29T20:00:35Z<p>Acabunoc: /* Contributing */</p>
<hr />
<div>This page describes the development model used by the web development team at WormBase using git as our version control system. This includes our branching strategy and release management. We use git and GitHub to help us manage development.<br />
<br />
= Overview Diagram =<br />
[[File:Git_Workflow_-_WormBase4.png]]<br />
<br />
[https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing Editable version of the diagram]<br />
<br />
= Contributing =<br />
<br />
Whenever you begin work on a new issue you should create a new branch for it. Any new features should branch off <code>staging</code>. Once the feature is ready for testing, you can submit a pull request to <code>staging</code> for code review. Feature branches aren't necessarily branches in the main repository - they can in the main WormBase repository, or on a developer's fork. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Branch_stratgey Read more on our branching strategy]<br />
<br />
git checkout -b myFeature staging<br />
<br />
Now you can make your changes and commit some code. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Commit_messages Read more on commit messages]<br />
git add /PATH/TO/UPDATED/FILE<br />
git commit -m "Descriptive commit message"<br />
<br />
When you're ready, you can push your branch to GitHub<br />
<br />
git push origin myFeature<br />
<br />
Continue making changes until your code is ready for a code review. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Is_my_code_ready_for_review.3F Is my code ready for review?]<br />
<br />
When your code is ready, go to GitHub and create a Pull Request. [http://nathanhoad.net/git-workflow-forks-remotes-and-pull-requests More info on Pull Requests.]<br />
<br />
# Go to the repository where you pushed your changes<br />
# Switch to your branch (myFeature)<br />
# Click the green '''Compare & review''' button<br />
# After reviewing all the changes, click on '''Create pull request''' in the header to send the pull request<br />
# In the description, write a short summary of the issues (along with a link to the issue) and changes made along with some links for testing <br />
#* [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#What_info_should_I_include_in_a_Pull_Request.3F What info should I include in a Pull Request?]<br />
<br />
Wait for another member of the web development team to review and merge your pull request. If more changes are requested, you can push more commits to the same branch and it will be added to the pull request.<br />
<br />
Once your pull request is merged, locally bring in the changes and delete your issue branch<br />
git checkout staging<br />
git pull<br />
git branch -d myFeature<br />
<br />
Go to the original github issue:<br />
# Add the '''Under testing''' label to your issue<br />
# Comment on the issue to notify all involved that it is ready for testing. Add links for testing for the ease of testers.<br />
# Another member of the WormBase group will close the issue once they have tested it<br />
<br />
Note: You can view all merged pull requests using this link: https://github.com/WormBase/website/pulls?q=is%3Apr+is%3Amerged<br />
== Is my code ready for review? == <br />
<br />
Before you send a Pull Request, please make sure you have completed the following:<br />
<br />
* Written tests (API tests or REST tests) demonstrating the problem in the issue. [http://wiki.wormbase.org/index.php/Unit_Testing More info on testing]<br />
* Fix the problem (ie pass the tests)<br />
* Complete the issue as much as possible without curators seeing an example<br />
* Code style meeting the [http://wiki.wormbase.org/index.php/Coding_standards WormBase coding standards] (indentation, comments, no debug statements)<br />
<br />
== What info should I include in a Pull Request? ==<br />
<br />
To help your reviewer understand your code, please try to include the following in the Pull Request description<br />
<br />
* A link to the issue being addressed<br />
* Short summary of the problem<br />
* Some links to use for testing<br />
* Any other information that may be needed to testing (ie wormbase_local.conf changes, extra files needed, etc)<br />
<br />
== Commit messages ==<br />
git commit -m "COMMIT MESSAGE GOES HERE"<br />
<br />
Keep your commit message as descriptive as possible, reference any issues affected by the issue number (#YYY):<br />
This is a summary of my commit.<br />
* here is a breakdown of the different changes<br />
* mention github users (@tharris) when appropriate<br />
* related to #529<br />
* #945<br />
<br />
Here is a template originally written by Tim Pope at tpope.net:<br />
<pre><br />
Short (50 chars or less) summary of changes<br />
<br />
More detailed explanatory text, if necessary. Wrap it to about 72<br />
characters or so. In some contexts, the first line is treated as the<br />
subject of an email and the rest of the text as the body. The blank<br />
line separating the summary from the body is critical (unless you omit<br />
the body entirely); tools like rebase can get confused if you run the<br />
two together.<br />
<br />
Further paragraphs come after blank lines.<br />
<br />
- Bullet points are okay, too<br />
<br />
- Typically a hyphen or asterisk is used for the bullet, preceded by a<br />
single space, with blank lines in between, but conventions vary here<br />
</pre><br />
<br />
= Code Review =<br />
<br />
All changes must go through a code review before being merged to the staging branch. At WormBase, this is done using Pull Requests. All members of the core development team are expected to keep an eye on the open Pull Requests and reviewing the ones they are assigned.<br />
<br />
* Test out the pull request (check out the branch)<br />
* Take a quick look at the code (are there comments? anything obvious missing)<br />
* Run the tests written for this issue<br />
* Leave a comment on the PR if you notice anything that needs to be fixed<br />
* Merge the PR if you think it looks good<br />
** Begin by merging staging into the feature branch.<br />
** If there are conflicts, ask the owner of the PR to help resolve them.<br />
<br />
= Testing =<br />
All issues need to be tested and closed by at least one person who is not the developer who made the change. Ideally, it would be the curator asking for the feature/fix.<br />
<br />
'''If you would like to help test''':<br />
* Look at the [https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']. <br />
* All the changes for these issues are available for testing on [http://staging.wormbase.org staging.wormbase.org].<br />
* You can test out the changes and leave any feedback you have in the issue comments. <br />
* If you think this feature/fix is ready for production, please '''close the issue'''.<br />
<br />
= Branch Strategy =<br />
We use branches to help with our release management, testing strategy, and helping with parallel development among the team.<br />
<br />
== Main branches ==<br />
Inside the <code>WormBase/website</code> repository, there are three main branches: <code>master</code>, <code>staging</code> and <code>production</code>.<br />
<br />
* <code>master</code>: current, stable code. All new changes brought into master have been tested on [http://staging.wormbase.org staging.wormbase.org] and approved by either the curator requesting the change, or the development lead.<br />
<br />
* <code>staging</code>: all changes get pushed to the <code>staging</code> branch after code review. This code gets pushed immediately to [http://staging.wormbase.org staging.wormbase.org].<br />
<br />
* <code>production</code>: the code currently in production. Branched off of <code>master</code> at each release.<br />
<br />
== Feature branches ==<br />
Any new features should branch off <code>staging</code>. Read more on feature branches in [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Contributing our contribution guidelines]<br />
<br />
== Hotfixes ==<br />
If a major bugfix is needed in production, create a hotfix branch from production. When finished, the branch needs to be merged (via PR/code review) back into <code>production</code> and <code>staging</code><br />
<br />
=== Begining a fix ===<br />
git checkout -b hotfix-issXXX production<br />
<br />
Fix the bug and commit the fix in one or more commits. Reference the github issue:<br />
git commit -m "Severe production bug<br />
* search redirecting to home page<br />
* fix #XXX"<br />
<br />
=== Closing the fix ===<br />
To close the fix, send a Pull Request to both the <code>production</code> and <code>staging</code> for code review. The reviewer will merge the branch.<br />
<br />
= Development Timeline =<br />
<br />
See: [https://docs.google.com/document/d/1zIOm95tV9A14n9xnkPkMgiOTGcOIzx161y9UbDZvfW4/pub WormBase Release Workflow]<br />
<br />
= Release Management =<br />
When production is ready to updated for release WSXXX:<br />
<br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:master...staging pull request from staging to master]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:production...master pull request from master to production]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Tag production branch with appropriate release name.<br />
<br />
<br />
git checkout production<br />
git tag -a WSXXX<br />
<br />
= Links =<br />
* [http://staging.wormbase.org staging site for testing]<br />
* [https://github.com/WormBase/website github repository]<br />
* [https://github.com/WormBase/website/issues github issue tracker]<br />
* [https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing workflow diagram]<br />
<br />
[[Category:Development General (Web Dev)]]<br />
[[Category:Getting Started (Web Dev)]]</div>Acabunochttps://wiki.wormbase.org/index.php?title=Development_workflow_-_webdev&diff=24309Development workflow - webdev2014-07-29T19:29:26Z<p>Acabunoc: /* Closing the fix */</p>
<hr />
<div>This page describes the development model used by the web development team at WormBase using git as our version control system. This includes our branching strategy and release management. We use git and GitHub to help us manage development.<br />
<br />
= Overview Diagram =<br />
[[File:Git_Workflow_-_WormBase4.png]]<br />
<br />
[https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing Editable version of the diagram]<br />
<br />
= Contributing =<br />
<br />
Whenever you begin work on a new issue you should create a new branch for it. Any new features should branch off <code>staging</code>. Once the feature is ready for testing, you can submit a pull request to <code>staging</code> for code review. Feature branches aren't necessarily branches in the main repository - they can in the main WormBase repository, or on a developer's fork. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Branch_stratgey Read more on our branching strategy]<br />
<br />
git checkout -b myFeature staging<br />
<br />
Now you can make your changes and commit some code. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Commit_messages Read more on commit messages]<br />
git add /PATH/TO/UPDATED/FILE<br />
git commit -m "Descriptive commit message"<br />
<br />
When you're ready, you can push your branch to GitHub<br />
<br />
git push origin myFeature<br />
<br />
Continue making changes until your code is ready for a code review. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Is_my_code_ready_for_review.3F Is my code ready for review?]<br />
<br />
When your code is ready, go to GitHub and create a Pull Request. [http://nathanhoad.net/git-workflow-forks-remotes-and-pull-requests More info on Pull Requests.]<br />
<br />
# Go to the repository where you pushed your changes<br />
# Switch to your branch (myFeature)<br />
# Click the green '''Compare & review''' button<br />
# After reviewing all the changes, click on '''Create pull request''' in the header to send the pull request<br />
# In the description, write a short summary of the issues (along with a link to the issue) and changes made along with some links for testing [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#What_info_should_I_include_in_a_Pull_Request.3F What info should I include in a Pull Request?]<br />
<br />
Wait for another member of the web development team to review and merge your pull request. If more changes are requested, you can push more commits to the same branch and it will be added to the pull request.<br />
<br />
Once your pull request is merged, locally bring in the changes and delete your issue branch<br />
git checkout staging<br />
git pull<br />
git branch -d myFeature<br />
<br />
Go to the original github issue:<br />
# Add the '''Under testing''' label to your issue<br />
# Comment on the issue to notify all involved that it is ready for testing. Add links for testing for the ease of testers.<br />
# Another member of the WormBase group will close the issue once they have tested it<br />
<br />
Note: You can view all merged pull requests using this link: https://github.com/WormBase/website/pulls?q=is%3Apr+is%3Amerged<br />
== Is my code ready for review? == <br />
<br />
Before you send a Pull Request, please make sure you have completed the following:<br />
<br />
* Written tests (API tests or REST tests) demonstrating the problem in the issue. [http://wiki.wormbase.org/index.php/Unit_Testing More info on testing]<br />
* Fix the problem (ie pass the tests)<br />
* Complete the issue as much as possible without curators seeing an example<br />
* Code style meeting the [http://wiki.wormbase.org/index.php/Coding_standards WormBase coding standards] (indentation, comments, no debug statements)<br />
<br />
== What info should I include in a Pull Request? ==<br />
<br />
To help your reviewer understand your code, please try to include the following in the Pull Request description<br />
<br />
* A link to the issue being addressed<br />
* Short summary of the problem<br />
* Some links to use for testing<br />
* Any other information that may be needed to testing (ie wormbase_local.conf changes, extra files needed, etc)<br />
<br />
== Commit messages ==<br />
git commit -m "COMMIT MESSAGE GOES HERE"<br />
<br />
Keep your commit message as descriptive as possible, reference any issues affected by the issue number (#YYY):<br />
This is a summary of my commit.<br />
* here is a breakdown of the different changes<br />
* mention github users (@tharris) when appropriate<br />
* related to #529<br />
* #945<br />
<br />
Here is a template originally written by Tim Pope at tpope.net:<br />
<pre><br />
Short (50 chars or less) summary of changes<br />
<br />
More detailed explanatory text, if necessary. Wrap it to about 72<br />
characters or so. In some contexts, the first line is treated as the<br />
subject of an email and the rest of the text as the body. The blank<br />
line separating the summary from the body is critical (unless you omit<br />
the body entirely); tools like rebase can get confused if you run the<br />
two together.<br />
<br />
Further paragraphs come after blank lines.<br />
<br />
- Bullet points are okay, too<br />
<br />
- Typically a hyphen or asterisk is used for the bullet, preceded by a<br />
single space, with blank lines in between, but conventions vary here<br />
</pre><br />
<br />
= Code Review =<br />
<br />
All changes must go through a code review before being merged to the staging branch. At WormBase, this is done using Pull Requests. All members of the core development team are expected to keep an eye on the open Pull Requests and reviewing the ones they are assigned.<br />
<br />
* Test out the pull request (check out the branch)<br />
* Take a quick look at the code (are there comments? anything obvious missing)<br />
* Run the tests written for this issue<br />
* Leave a comment on the PR if you notice anything that needs to be fixed<br />
* Merge the PR if you think it looks good<br />
** Begin by merging staging into the feature branch.<br />
** If there are conflicts, ask the owner of the PR to help resolve them.<br />
<br />
= Testing =<br />
All issues need to be tested and closed by at least one person who is not the developer who made the change. Ideally, it would be the curator asking for the feature/fix.<br />
<br />
'''If you would like to help test''':<br />
* Look at the [https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']. <br />
* All the changes for these issues are available for testing on [http://staging.wormbase.org staging.wormbase.org].<br />
* You can test out the changes and leave any feedback you have in the issue comments. <br />
* If you think this feature/fix is ready for production, please '''close the issue'''.<br />
<br />
= Branch Strategy =<br />
We use branches to help with our release management, testing strategy, and helping with parallel development among the team.<br />
<br />
== Main branches ==<br />
Inside the <code>WormBase/website</code> repository, there are three main branches: <code>master</code>, <code>staging</code> and <code>production</code>.<br />
<br />
* <code>master</code>: current, stable code. All new changes brought into master have been tested on [http://staging.wormbase.org staging.wormbase.org] and approved by either the curator requesting the change, or the development lead.<br />
<br />
* <code>staging</code>: all changes get pushed to the <code>staging</code> branch after code review. This code gets pushed immediately to [http://staging.wormbase.org staging.wormbase.org].<br />
<br />
* <code>production</code>: the code currently in production. Branched off of <code>master</code> at each release.<br />
<br />
== Feature branches ==<br />
Any new features should branch off <code>staging</code>. Read more on feature branches in [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Contributing our contribution guidelines]<br />
<br />
== Hotfixes ==<br />
If a major bugfix is needed in production, create a hotfix branch from production. When finished, the branch needs to be merged (via PR/code review) back into <code>production</code> and <code>staging</code><br />
<br />
=== Begining a fix ===<br />
git checkout -b hotfix-issXXX production<br />
<br />
Fix the bug and commit the fix in one or more commits. Reference the github issue:<br />
git commit -m "Severe production bug<br />
* search redirecting to home page<br />
* fix #XXX"<br />
<br />
=== Closing the fix ===<br />
To close the fix, send a Pull Request to both the <code>production</code> and <code>staging</code> for code review. The reviewer will merge the branch.<br />
<br />
= Development Timeline =<br />
<br />
See: [https://docs.google.com/document/d/1zIOm95tV9A14n9xnkPkMgiOTGcOIzx161y9UbDZvfW4/pub WormBase Release Workflow]<br />
<br />
= Release Management =<br />
When production is ready to updated for release WSXXX:<br />
<br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:master...staging pull request from staging to master]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:production...master pull request from master to production]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Tag production branch with appropriate release name.<br />
<br />
<br />
git checkout production<br />
git tag -a WSXXX<br />
<br />
= Links =<br />
* [http://staging.wormbase.org staging site for testing]<br />
* [https://github.com/WormBase/website github repository]<br />
* [https://github.com/WormBase/website/issues github issue tracker]<br />
* [https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing workflow diagram]<br />
<br />
[[Category:Development General (Web Dev)]]<br />
[[Category:Getting Started (Web Dev)]]</div>Acabunochttps://wiki.wormbase.org/index.php?title=Development_workflow_-_webdev&diff=24308Development workflow - webdev2014-07-29T19:27:59Z<p>Acabunoc: /* Hotfixes */</p>
<hr />
<div>This page describes the development model used by the web development team at WormBase using git as our version control system. This includes our branching strategy and release management. We use git and GitHub to help us manage development.<br />
<br />
= Overview Diagram =<br />
[[File:Git_Workflow_-_WormBase4.png]]<br />
<br />
[https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing Editable version of the diagram]<br />
<br />
= Contributing =<br />
<br />
Whenever you begin work on a new issue you should create a new branch for it. Any new features should branch off <code>staging</code>. Once the feature is ready for testing, you can submit a pull request to <code>staging</code> for code review. Feature branches aren't necessarily branches in the main repository - they can in the main WormBase repository, or on a developer's fork. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Branch_stratgey Read more on our branching strategy]<br />
<br />
git checkout -b myFeature staging<br />
<br />
Now you can make your changes and commit some code. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Commit_messages Read more on commit messages]<br />
git add /PATH/TO/UPDATED/FILE<br />
git commit -m "Descriptive commit message"<br />
<br />
When you're ready, you can push your branch to GitHub<br />
<br />
git push origin myFeature<br />
<br />
Continue making changes until your code is ready for a code review. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Is_my_code_ready_for_review.3F Is my code ready for review?]<br />
<br />
When your code is ready, go to GitHub and create a Pull Request. [http://nathanhoad.net/git-workflow-forks-remotes-and-pull-requests More info on Pull Requests.]<br />
<br />
# Go to the repository where you pushed your changes<br />
# Switch to your branch (myFeature)<br />
# Click the green '''Compare & review''' button<br />
# After reviewing all the changes, click on '''Create pull request''' in the header to send the pull request<br />
# In the description, write a short summary of the issues (along with a link to the issue) and changes made along with some links for testing [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#What_info_should_I_include_in_a_Pull_Request.3F What info should I include in a Pull Request?]<br />
<br />
Wait for another member of the web development team to review and merge your pull request. If more changes are requested, you can push more commits to the same branch and it will be added to the pull request.<br />
<br />
Once your pull request is merged, locally bring in the changes and delete your issue branch<br />
git checkout staging<br />
git pull<br />
git branch -d myFeature<br />
<br />
Go to the original github issue:<br />
# Add the '''Under testing''' label to your issue<br />
# Comment on the issue to notify all involved that it is ready for testing. Add links for testing for the ease of testers.<br />
# Another member of the WormBase group will close the issue once they have tested it<br />
<br />
Note: You can view all merged pull requests using this link: https://github.com/WormBase/website/pulls?q=is%3Apr+is%3Amerged<br />
== Is my code ready for review? == <br />
<br />
Before you send a Pull Request, please make sure you have completed the following:<br />
<br />
* Written tests (API tests or REST tests) demonstrating the problem in the issue. [http://wiki.wormbase.org/index.php/Unit_Testing More info on testing]<br />
* Fix the problem (ie pass the tests)<br />
* Complete the issue as much as possible without curators seeing an example<br />
* Code style meeting the [http://wiki.wormbase.org/index.php/Coding_standards WormBase coding standards] (indentation, comments, no debug statements)<br />
<br />
== What info should I include in a Pull Request? ==<br />
<br />
To help your reviewer understand your code, please try to include the following in the Pull Request description<br />
<br />
* A link to the issue being addressed<br />
* Short summary of the problem<br />
* Some links to use for testing<br />
* Any other information that may be needed to testing (ie wormbase_local.conf changes, extra files needed, etc)<br />
<br />
== Commit messages ==<br />
git commit -m "COMMIT MESSAGE GOES HERE"<br />
<br />
Keep your commit message as descriptive as possible, reference any issues affected by the issue number (#YYY):<br />
This is a summary of my commit.<br />
* here is a breakdown of the different changes<br />
* mention github users (@tharris) when appropriate<br />
* related to #529<br />
* #945<br />
<br />
Here is a template originally written by Tim Pope at tpope.net:<br />
<pre><br />
Short (50 chars or less) summary of changes<br />
<br />
More detailed explanatory text, if necessary. Wrap it to about 72<br />
characters or so. In some contexts, the first line is treated as the<br />
subject of an email and the rest of the text as the body. The blank<br />
line separating the summary from the body is critical (unless you omit<br />
the body entirely); tools like rebase can get confused if you run the<br />
two together.<br />
<br />
Further paragraphs come after blank lines.<br />
<br />
- Bullet points are okay, too<br />
<br />
- Typically a hyphen or asterisk is used for the bullet, preceded by a<br />
single space, with blank lines in between, but conventions vary here<br />
</pre><br />
<br />
= Code Review =<br />
<br />
All changes must go through a code review before being merged to the staging branch. At WormBase, this is done using Pull Requests. All members of the core development team are expected to keep an eye on the open Pull Requests and reviewing the ones they are assigned.<br />
<br />
* Test out the pull request (check out the branch)<br />
* Take a quick look at the code (are there comments? anything obvious missing)<br />
* Run the tests written for this issue<br />
* Leave a comment on the PR if you notice anything that needs to be fixed<br />
* Merge the PR if you think it looks good<br />
** Begin by merging staging into the feature branch.<br />
** If there are conflicts, ask the owner of the PR to help resolve them.<br />
<br />
= Testing =<br />
All issues need to be tested and closed by at least one person who is not the developer who made the change. Ideally, it would be the curator asking for the feature/fix.<br />
<br />
'''If you would like to help test''':<br />
* Look at the [https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']. <br />
* All the changes for these issues are available for testing on [http://staging.wormbase.org staging.wormbase.org].<br />
* You can test out the changes and leave any feedback you have in the issue comments. <br />
* If you think this feature/fix is ready for production, please '''close the issue'''.<br />
<br />
= Branch Strategy =<br />
We use branches to help with our release management, testing strategy, and helping with parallel development among the team.<br />
<br />
== Main branches ==<br />
Inside the <code>WormBase/website</code> repository, there are three main branches: <code>master</code>, <code>staging</code> and <code>production</code>.<br />
<br />
* <code>master</code>: current, stable code. All new changes brought into master have been tested on [http://staging.wormbase.org staging.wormbase.org] and approved by either the curator requesting the change, or the development lead.<br />
<br />
* <code>staging</code>: all changes get pushed to the <code>staging</code> branch after code review. This code gets pushed immediately to [http://staging.wormbase.org staging.wormbase.org].<br />
<br />
* <code>production</code>: the code currently in production. Branched off of <code>master</code> at each release.<br />
<br />
== Feature branches ==<br />
Any new features should branch off <code>staging</code>. Read more on feature branches in [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Contributing our contribution guidelines]<br />
<br />
== Hotfixes ==<br />
If a major bugfix is needed in production, create a hotfix branch from production. When finished, the branch needs to be merged (via PR/code review) back into <code>production</code> and <code>staging</code><br />
<br />
=== Begining a fix ===<br />
git checkout -b hotfix-issXXX production<br />
<br />
Fix the bug and commit the fix in one or more commits. Reference the github issue:<br />
git commit -m "Severe production bug<br />
* search redirecting to home page<br />
* fix #XXX"<br />
<br />
=== Closing the fix ===<br />
The fix needs to be merged back to both <code>production</code> and <code>staging</code><br />
git checkout staging<br />
git merge hotfix-issXXX<br />
<br />
git checkout production<br />
git merge hotfix-issXXX<br />
<br />
= Development Timeline =<br />
<br />
See: [https://docs.google.com/document/d/1zIOm95tV9A14n9xnkPkMgiOTGcOIzx161y9UbDZvfW4/pub WormBase Release Workflow]<br />
<br />
= Release Management =<br />
When production is ready to updated for release WSXXX:<br />
<br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:master...staging pull request from staging to master]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:production...master pull request from master to production]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Tag production branch with appropriate release name.<br />
<br />
<br />
git checkout production<br />
git tag -a WSXXX<br />
<br />
= Links =<br />
* [http://staging.wormbase.org staging site for testing]<br />
* [https://github.com/WormBase/website github repository]<br />
* [https://github.com/WormBase/website/issues github issue tracker]<br />
* [https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing workflow diagram]<br />
<br />
[[Category:Development General (Web Dev)]]<br />
[[Category:Getting Started (Web Dev)]]</div>Acabunochttps://wiki.wormbase.org/index.php?title=Development_workflow_-_webdev&diff=24307Development workflow - webdev2014-07-29T19:27:34Z<p>Acabunoc: /* Feature branches */</p>
<hr />
<div>This page describes the development model used by the web development team at WormBase using git as our version control system. This includes our branching strategy and release management. We use git and GitHub to help us manage development.<br />
<br />
= Overview Diagram =<br />
[[File:Git_Workflow_-_WormBase4.png]]<br />
<br />
[https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing Editable version of the diagram]<br />
<br />
= Contributing =<br />
<br />
Whenever you begin work on a new issue you should create a new branch for it. Any new features should branch off <code>staging</code>. Once the feature is ready for testing, you can submit a pull request to <code>staging</code> for code review. Feature branches aren't necessarily branches in the main repository - they can in the main WormBase repository, or on a developer's fork. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Branch_stratgey Read more on our branching strategy]<br />
<br />
git checkout -b myFeature staging<br />
<br />
Now you can make your changes and commit some code. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Commit_messages Read more on commit messages]<br />
git add /PATH/TO/UPDATED/FILE<br />
git commit -m "Descriptive commit message"<br />
<br />
When you're ready, you can push your branch to GitHub<br />
<br />
git push origin myFeature<br />
<br />
Continue making changes until your code is ready for a code review. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Is_my_code_ready_for_review.3F Is my code ready for review?]<br />
<br />
When your code is ready, go to GitHub and create a Pull Request. [http://nathanhoad.net/git-workflow-forks-remotes-and-pull-requests More info on Pull Requests.]<br />
<br />
# Go to the repository where you pushed your changes<br />
# Switch to your branch (myFeature)<br />
# Click the green '''Compare & review''' button<br />
# After reviewing all the changes, click on '''Create pull request''' in the header to send the pull request<br />
# In the description, write a short summary of the issues (along with a link to the issue) and changes made along with some links for testing [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#What_info_should_I_include_in_a_Pull_Request.3F What info should I include in a Pull Request?]<br />
<br />
Wait for another member of the web development team to review and merge your pull request. If more changes are requested, you can push more commits to the same branch and it will be added to the pull request.<br />
<br />
Once your pull request is merged, locally bring in the changes and delete your issue branch<br />
git checkout staging<br />
git pull<br />
git branch -d myFeature<br />
<br />
Go to the original github issue:<br />
# Add the '''Under testing''' label to your issue<br />
# Comment on the issue to notify all involved that it is ready for testing. Add links for testing for the ease of testers.<br />
# Another member of the WormBase group will close the issue once they have tested it<br />
<br />
Note: You can view all merged pull requests using this link: https://github.com/WormBase/website/pulls?q=is%3Apr+is%3Amerged<br />
== Is my code ready for review? == <br />
<br />
Before you send a Pull Request, please make sure you have completed the following:<br />
<br />
* Written tests (API tests or REST tests) demonstrating the problem in the issue. [http://wiki.wormbase.org/index.php/Unit_Testing More info on testing]<br />
* Fix the problem (ie pass the tests)<br />
* Complete the issue as much as possible without curators seeing an example<br />
* Code style meeting the [http://wiki.wormbase.org/index.php/Coding_standards WormBase coding standards] (indentation, comments, no debug statements)<br />
<br />
== What info should I include in a Pull Request? ==<br />
<br />
To help your reviewer understand your code, please try to include the following in the Pull Request description<br />
<br />
* A link to the issue being addressed<br />
* Short summary of the problem<br />
* Some links to use for testing<br />
* Any other information that may be needed to testing (ie wormbase_local.conf changes, extra files needed, etc)<br />
<br />
== Commit messages ==<br />
git commit -m "COMMIT MESSAGE GOES HERE"<br />
<br />
Keep your commit message as descriptive as possible, reference any issues affected by the issue number (#YYY):<br />
This is a summary of my commit.<br />
* here is a breakdown of the different changes<br />
* mention github users (@tharris) when appropriate<br />
* related to #529<br />
* #945<br />
<br />
Here is a template originally written by Tim Pope at tpope.net:<br />
<pre><br />
Short (50 chars or less) summary of changes<br />
<br />
More detailed explanatory text, if necessary. Wrap it to about 72<br />
characters or so. In some contexts, the first line is treated as the<br />
subject of an email and the rest of the text as the body. The blank<br />
line separating the summary from the body is critical (unless you omit<br />
the body entirely); tools like rebase can get confused if you run the<br />
two together.<br />
<br />
Further paragraphs come after blank lines.<br />
<br />
- Bullet points are okay, too<br />
<br />
- Typically a hyphen or asterisk is used for the bullet, preceded by a<br />
single space, with blank lines in between, but conventions vary here<br />
</pre><br />
<br />
= Code Review =<br />
<br />
All changes must go through a code review before being merged to the staging branch. At WormBase, this is done using Pull Requests. All members of the core development team are expected to keep an eye on the open Pull Requests and reviewing the ones they are assigned.<br />
<br />
* Test out the pull request (check out the branch)<br />
* Take a quick look at the code (are there comments? anything obvious missing)<br />
* Run the tests written for this issue<br />
* Leave a comment on the PR if you notice anything that needs to be fixed<br />
* Merge the PR if you think it looks good<br />
** Begin by merging staging into the feature branch.<br />
** If there are conflicts, ask the owner of the PR to help resolve them.<br />
<br />
= Testing =<br />
All issues need to be tested and closed by at least one person who is not the developer who made the change. Ideally, it would be the curator asking for the feature/fix.<br />
<br />
'''If you would like to help test''':<br />
* Look at the [https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']. <br />
* All the changes for these issues are available for testing on [http://staging.wormbase.org staging.wormbase.org].<br />
* You can test out the changes and leave any feedback you have in the issue comments. <br />
* If you think this feature/fix is ready for production, please '''close the issue'''.<br />
<br />
= Branch Strategy =<br />
We use branches to help with our release management, testing strategy, and helping with parallel development among the team.<br />
<br />
== Main branches ==<br />
Inside the <code>WormBase/website</code> repository, there are three main branches: <code>master</code>, <code>staging</code> and <code>production</code>.<br />
<br />
* <code>master</code>: current, stable code. All new changes brought into master have been tested on [http://staging.wormbase.org staging.wormbase.org] and approved by either the curator requesting the change, or the development lead.<br />
<br />
* <code>staging</code>: all changes get pushed to the <code>staging</code> branch after code review. This code gets pushed immediately to [http://staging.wormbase.org staging.wormbase.org].<br />
<br />
* <code>production</code>: the code currently in production. Branched off of <code>master</code> at each release.<br />
<br />
== Feature branches ==<br />
Any new features should branch off <code>staging</code>. Read more on feature branches in [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Contributing our contribution guidelines]<br />
<br />
== Hotfixes ==<br />
If a major bugfix is needed in production, create a hotfix branch from production. When finished, the branch needs to be merged back into <code>production</code> and <code>staging</code><br />
<br />
=== Begining a fix ===<br />
git checkout -b hotfix-issXXX production<br />
<br />
Fix the bug and commit the fix in one or more commits. Reference the github issue:<br />
git commit -m "Severe production bug<br />
* search redirecting to home page<br />
* fix #XXX"<br />
<br />
=== Closing the fix ===<br />
The fix needs to be merged back to both <code>production</code> and <code>staging</code><br />
git checkout staging<br />
git merge hotfix-issXXX<br />
<br />
git checkout production<br />
git merge hotfix-issXXX<br />
<br />
= Development Timeline =<br />
<br />
See: [https://docs.google.com/document/d/1zIOm95tV9A14n9xnkPkMgiOTGcOIzx161y9UbDZvfW4/pub WormBase Release Workflow]<br />
<br />
= Release Management =<br />
When production is ready to updated for release WSXXX:<br />
<br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:master...staging pull request from staging to master]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:production...master pull request from master to production]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Tag production branch with appropriate release name.<br />
<br />
<br />
git checkout production<br />
git tag -a WSXXX<br />
<br />
= Links =<br />
* [http://staging.wormbase.org staging site for testing]<br />
* [https://github.com/WormBase/website github repository]<br />
* [https://github.com/WormBase/website/issues github issue tracker]<br />
* [https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing workflow diagram]<br />
<br />
[[Category:Development General (Web Dev)]]<br />
[[Category:Getting Started (Web Dev)]]</div>Acabunochttps://wiki.wormbase.org/index.php?title=Development_workflow_-_webdev&diff=24306Development workflow - webdev2014-07-29T19:26:28Z<p>Acabunoc: /* Main branches */</p>
<hr />
<div>This page describes the development model used by the web development team at WormBase using git as our version control system. This includes our branching strategy and release management. We use git and GitHub to help us manage development.<br />
<br />
= Overview Diagram =<br />
[[File:Git_Workflow_-_WormBase4.png]]<br />
<br />
[https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing Editable version of the diagram]<br />
<br />
= Contributing =<br />
<br />
Whenever you begin work on a new issue you should create a new branch for it. Any new features should branch off <code>staging</code>. Once the feature is ready for testing, you can submit a pull request to <code>staging</code> for code review. Feature branches aren't necessarily branches in the main repository - they can in the main WormBase repository, or on a developer's fork. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Branch_stratgey Read more on our branching strategy]<br />
<br />
git checkout -b myFeature staging<br />
<br />
Now you can make your changes and commit some code. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Commit_messages Read more on commit messages]<br />
git add /PATH/TO/UPDATED/FILE<br />
git commit -m "Descriptive commit message"<br />
<br />
When you're ready, you can push your branch to GitHub<br />
<br />
git push origin myFeature<br />
<br />
Continue making changes until your code is ready for a code review. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Is_my_code_ready_for_review.3F Is my code ready for review?]<br />
<br />
When your code is ready, go to GitHub and create a Pull Request. [http://nathanhoad.net/git-workflow-forks-remotes-and-pull-requests More info on Pull Requests.]<br />
<br />
# Go to the repository where you pushed your changes<br />
# Switch to your branch (myFeature)<br />
# Click the green '''Compare & review''' button<br />
# After reviewing all the changes, click on '''Create pull request''' in the header to send the pull request<br />
# In the description, write a short summary of the issues (along with a link to the issue) and changes made along with some links for testing [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#What_info_should_I_include_in_a_Pull_Request.3F What info should I include in a Pull Request?]<br />
<br />
Wait for another member of the web development team to review and merge your pull request. If more changes are requested, you can push more commits to the same branch and it will be added to the pull request.<br />
<br />
Once your pull request is merged, locally bring in the changes and delete your issue branch<br />
git checkout staging<br />
git pull<br />
git branch -d myFeature<br />
<br />
Go to the original github issue:<br />
# Add the '''Under testing''' label to your issue<br />
# Comment on the issue to notify all involved that it is ready for testing. Add links for testing for the ease of testers.<br />
# Another member of the WormBase group will close the issue once they have tested it<br />
<br />
Note: You can view all merged pull requests using this link: https://github.com/WormBase/website/pulls?q=is%3Apr+is%3Amerged<br />
== Is my code ready for review? == <br />
<br />
Before you send a Pull Request, please make sure you have completed the following:<br />
<br />
* Written tests (API tests or REST tests) demonstrating the problem in the issue. [http://wiki.wormbase.org/index.php/Unit_Testing More info on testing]<br />
* Fix the problem (ie pass the tests)<br />
* Complete the issue as much as possible without curators seeing an example<br />
* Code style meeting the [http://wiki.wormbase.org/index.php/Coding_standards WormBase coding standards] (indentation, comments, no debug statements)<br />
<br />
== What info should I include in a Pull Request? ==<br />
<br />
To help your reviewer understand your code, please try to include the following in the Pull Request description<br />
<br />
* A link to the issue being addressed<br />
* Short summary of the problem<br />
* Some links to use for testing<br />
* Any other information that may be needed to testing (ie wormbase_local.conf changes, extra files needed, etc)<br />
<br />
== Commit messages ==<br />
git commit -m "COMMIT MESSAGE GOES HERE"<br />
<br />
Keep your commit message as descriptive as possible, reference any issues affected by the issue number (#YYY):<br />
This is a summary of my commit.<br />
* here is a breakdown of the different changes<br />
* mention github users (@tharris) when appropriate<br />
* related to #529<br />
* #945<br />
<br />
Here is a template originally written by Tim Pope at tpope.net:<br />
<pre><br />
Short (50 chars or less) summary of changes<br />
<br />
More detailed explanatory text, if necessary. Wrap it to about 72<br />
characters or so. In some contexts, the first line is treated as the<br />
subject of an email and the rest of the text as the body. The blank<br />
line separating the summary from the body is critical (unless you omit<br />
the body entirely); tools like rebase can get confused if you run the<br />
two together.<br />
<br />
Further paragraphs come after blank lines.<br />
<br />
- Bullet points are okay, too<br />
<br />
- Typically a hyphen or asterisk is used for the bullet, preceded by a<br />
single space, with blank lines in between, but conventions vary here<br />
</pre><br />
<br />
= Code Review =<br />
<br />
All changes must go through a code review before being merged to the staging branch. At WormBase, this is done using Pull Requests. All members of the core development team are expected to keep an eye on the open Pull Requests and reviewing the ones they are assigned.<br />
<br />
* Test out the pull request (check out the branch)<br />
* Take a quick look at the code (are there comments? anything obvious missing)<br />
* Run the tests written for this issue<br />
* Leave a comment on the PR if you notice anything that needs to be fixed<br />
* Merge the PR if you think it looks good<br />
** Begin by merging staging into the feature branch.<br />
** If there are conflicts, ask the owner of the PR to help resolve them.<br />
<br />
= Testing =<br />
All issues need to be tested and closed by at least one person who is not the developer who made the change. Ideally, it would be the curator asking for the feature/fix.<br />
<br />
'''If you would like to help test''':<br />
* Look at the [https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']. <br />
* All the changes for these issues are available for testing on [http://staging.wormbase.org staging.wormbase.org].<br />
* You can test out the changes and leave any feedback you have in the issue comments. <br />
* If you think this feature/fix is ready for production, please '''close the issue'''.<br />
<br />
= Branch Strategy =<br />
We use branches to help with our release management, testing strategy, and helping with parallel development among the team.<br />
<br />
== Main branches ==<br />
Inside the <code>WormBase/website</code> repository, there are three main branches: <code>master</code>, <code>staging</code> and <code>production</code>.<br />
<br />
* <code>master</code>: current, stable code. All new changes brought into master have been tested on [http://staging.wormbase.org staging.wormbase.org] and approved by either the curator requesting the change, or the development lead.<br />
<br />
* <code>staging</code>: all changes get pushed to the <code>staging</code> branch after code review. This code gets pushed immediately to [http://staging.wormbase.org staging.wormbase.org].<br />
<br />
* <code>production</code>: the code currently in production. Branched off of <code>master</code> at each release.<br />
<br />
== Feature branches ==<br />
Any new major features should branch off <code>staging</code>. Once the feature is ready for testing, it can be merged back into <code>staging</code>. These aren't necessarily branches in the main repository - can be local, or on a developer's fork.<br />
<br />
<br />
== Hotfixes ==<br />
If a major bugfix is needed in production, create a hotfix branch from production. When finished, the branch needs to be merged back into <code>production</code> and <code>staging</code><br />
<br />
=== Begining a fix ===<br />
git checkout -b hotfix-issXXX production<br />
<br />
Fix the bug and commit the fix in one or more commits. Reference the github issue:<br />
git commit -m "Severe production bug<br />
* search redirecting to home page<br />
* fix #XXX"<br />
<br />
=== Closing the fix ===<br />
The fix needs to be merged back to both <code>production</code> and <code>staging</code><br />
git checkout staging<br />
git merge hotfix-issXXX<br />
<br />
git checkout production<br />
git merge hotfix-issXXX<br />
<br />
= Development Timeline =<br />
<br />
See: [https://docs.google.com/document/d/1zIOm95tV9A14n9xnkPkMgiOTGcOIzx161y9UbDZvfW4/pub WormBase Release Workflow]<br />
<br />
= Release Management =<br />
When production is ready to updated for release WSXXX:<br />
<br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:master...staging pull request from staging to master]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:production...master pull request from master to production]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Tag production branch with appropriate release name.<br />
<br />
<br />
git checkout production<br />
git tag -a WSXXX<br />
<br />
= Links =<br />
* [http://staging.wormbase.org staging site for testing]<br />
* [https://github.com/WormBase/website github repository]<br />
* [https://github.com/WormBase/website/issues github issue tracker]<br />
* [https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing workflow diagram]<br />
<br />
[[Category:Development General (Web Dev)]]<br />
[[Category:Getting Started (Web Dev)]]</div>Acabunochttps://wiki.wormbase.org/index.php?title=Development_workflow_-_webdev&diff=24305Development workflow - webdev2014-07-29T19:24:42Z<p>Acabunoc: /* Testing */</p>
<hr />
<div>This page describes the development model used by the web development team at WormBase using git as our version control system. This includes our branching strategy and release management. We use git and GitHub to help us manage development.<br />
<br />
= Overview Diagram =<br />
[[File:Git_Workflow_-_WormBase4.png]]<br />
<br />
[https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing Editable version of the diagram]<br />
<br />
= Contributing =<br />
<br />
Whenever you begin work on a new issue you should create a new branch for it. Any new features should branch off <code>staging</code>. Once the feature is ready for testing, you can submit a pull request to <code>staging</code> for code review. Feature branches aren't necessarily branches in the main repository - they can in the main WormBase repository, or on a developer's fork. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Branch_stratgey Read more on our branching strategy]<br />
<br />
git checkout -b myFeature staging<br />
<br />
Now you can make your changes and commit some code. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Commit_messages Read more on commit messages]<br />
git add /PATH/TO/UPDATED/FILE<br />
git commit -m "Descriptive commit message"<br />
<br />
When you're ready, you can push your branch to GitHub<br />
<br />
git push origin myFeature<br />
<br />
Continue making changes until your code is ready for a code review. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Is_my_code_ready_for_review.3F Is my code ready for review?]<br />
<br />
When your code is ready, go to GitHub and create a Pull Request. [http://nathanhoad.net/git-workflow-forks-remotes-and-pull-requests More info on Pull Requests.]<br />
<br />
# Go to the repository where you pushed your changes<br />
# Switch to your branch (myFeature)<br />
# Click the green '''Compare & review''' button<br />
# After reviewing all the changes, click on '''Create pull request''' in the header to send the pull request<br />
# In the description, write a short summary of the issues (along with a link to the issue) and changes made along with some links for testing [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#What_info_should_I_include_in_a_Pull_Request.3F What info should I include in a Pull Request?]<br />
<br />
Wait for another member of the web development team to review and merge your pull request. If more changes are requested, you can push more commits to the same branch and it will be added to the pull request.<br />
<br />
Once your pull request is merged, locally bring in the changes and delete your issue branch<br />
git checkout staging<br />
git pull<br />
git branch -d myFeature<br />
<br />
Go to the original github issue:<br />
# Add the '''Under testing''' label to your issue<br />
# Comment on the issue to notify all involved that it is ready for testing. Add links for testing for the ease of testers.<br />
# Another member of the WormBase group will close the issue once they have tested it<br />
<br />
Note: You can view all merged pull requests using this link: https://github.com/WormBase/website/pulls?q=is%3Apr+is%3Amerged<br />
== Is my code ready for review? == <br />
<br />
Before you send a Pull Request, please make sure you have completed the following:<br />
<br />
* Written tests (API tests or REST tests) demonstrating the problem in the issue. [http://wiki.wormbase.org/index.php/Unit_Testing More info on testing]<br />
* Fix the problem (ie pass the tests)<br />
* Complete the issue as much as possible without curators seeing an example<br />
* Code style meeting the [http://wiki.wormbase.org/index.php/Coding_standards WormBase coding standards] (indentation, comments, no debug statements)<br />
<br />
== What info should I include in a Pull Request? ==<br />
<br />
To help your reviewer understand your code, please try to include the following in the Pull Request description<br />
<br />
* A link to the issue being addressed<br />
* Short summary of the problem<br />
* Some links to use for testing<br />
* Any other information that may be needed to testing (ie wormbase_local.conf changes, extra files needed, etc)<br />
<br />
== Commit messages ==<br />
git commit -m "COMMIT MESSAGE GOES HERE"<br />
<br />
Keep your commit message as descriptive as possible, reference any issues affected by the issue number (#YYY):<br />
This is a summary of my commit.<br />
* here is a breakdown of the different changes<br />
* mention github users (@tharris) when appropriate<br />
* related to #529<br />
* #945<br />
<br />
Here is a template originally written by Tim Pope at tpope.net:<br />
<pre><br />
Short (50 chars or less) summary of changes<br />
<br />
More detailed explanatory text, if necessary. Wrap it to about 72<br />
characters or so. In some contexts, the first line is treated as the<br />
subject of an email and the rest of the text as the body. The blank<br />
line separating the summary from the body is critical (unless you omit<br />
the body entirely); tools like rebase can get confused if you run the<br />
two together.<br />
<br />
Further paragraphs come after blank lines.<br />
<br />
- Bullet points are okay, too<br />
<br />
- Typically a hyphen or asterisk is used for the bullet, preceded by a<br />
single space, with blank lines in between, but conventions vary here<br />
</pre><br />
<br />
= Code Review =<br />
<br />
All changes must go through a code review before being merged to the staging branch. At WormBase, this is done using Pull Requests. All members of the core development team are expected to keep an eye on the open Pull Requests and reviewing the ones they are assigned.<br />
<br />
* Test out the pull request (check out the branch)<br />
* Take a quick look at the code (are there comments? anything obvious missing)<br />
* Run the tests written for this issue<br />
* Leave a comment on the PR if you notice anything that needs to be fixed<br />
* Merge the PR if you think it looks good<br />
** Begin by merging staging into the feature branch.<br />
** If there are conflicts, ask the owner of the PR to help resolve them.<br />
<br />
= Testing =<br />
All issues need to be tested and closed by at least one person who is not the developer who made the change. Ideally, it would be the curator asking for the feature/fix.<br />
<br />
'''If you would like to help test''':<br />
* Look at the [https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']. <br />
* All the changes for these issues are available for testing on [http://staging.wormbase.org staging.wormbase.org].<br />
* You can test out the changes and leave any feedback you have in the issue comments. <br />
* If you think this feature/fix is ready for production, please '''close the issue'''.<br />
<br />
= Branch Strategy =<br />
We use branches to help with our release management, testing strategy, and helping with parallel development among the team.<br />
<br />
== Main branches ==<br />
Inside the <code>WormBase/website</code> repository, there are three main branches: <code>master</code>, <code>staging</code> and <code>production</code>.<br />
<br />
* <code>master</code>: current, stable code. All new changes brought into master have been tested on [http://staging.wormbase.org staging.wormbase.org] and approved by either the curator requesting the change, or the development lead.<br />
<br />
* <code>staging</code>: any features/changes ready for testing should be pushed to the <code>staging</code> branch. This code gets pushed nightly to [http://staging.wormbase.org staging.wormbase.org].<br />
<br />
* <code>production</code>: the code currently in production. Branched off of <code>master</code> at each release.<br />
<br />
== Feature branches ==<br />
Any new major features should branch off <code>staging</code>. Once the feature is ready for testing, it can be merged back into <code>staging</code>. These aren't necessarily branches in the main repository - can be local, or on a developer's fork.<br />
<br />
<br />
== Hotfixes ==<br />
If a major bugfix is needed in production, create a hotfix branch from production. When finished, the branch needs to be merged back into <code>production</code> and <code>staging</code><br />
<br />
=== Begining a fix ===<br />
git checkout -b hotfix-issXXX production<br />
<br />
Fix the bug and commit the fix in one or more commits. Reference the github issue:<br />
git commit -m "Severe production bug<br />
* search redirecting to home page<br />
* fix #XXX"<br />
<br />
=== Closing the fix ===<br />
The fix needs to be merged back to both <code>production</code> and <code>staging</code><br />
git checkout staging<br />
git merge hotfix-issXXX<br />
<br />
git checkout production<br />
git merge hotfix-issXXX<br />
<br />
= Development Timeline =<br />
<br />
See: [https://docs.google.com/document/d/1zIOm95tV9A14n9xnkPkMgiOTGcOIzx161y9UbDZvfW4/pub WormBase Release Workflow]<br />
<br />
= Release Management =<br />
When production is ready to updated for release WSXXX:<br />
<br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:master...staging pull request from staging to master]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:production...master pull request from master to production]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Tag production branch with appropriate release name.<br />
<br />
<br />
git checkout production<br />
git tag -a WSXXX<br />
<br />
= Links =<br />
* [http://staging.wormbase.org staging site for testing]<br />
* [https://github.com/WormBase/website github repository]<br />
* [https://github.com/WormBase/website/issues github issue tracker]<br />
* [https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing workflow diagram]<br />
<br />
[[Category:Development General (Web Dev)]]<br />
[[Category:Getting Started (Web Dev)]]</div>Acabunochttps://wiki.wormbase.org/index.php?title=Development_workflow_-_webdev&diff=24304Development workflow - webdev2014-07-29T19:23:45Z<p>Acabunoc: /* Code Review */</p>
<hr />
<div>This page describes the development model used by the web development team at WormBase using git as our version control system. This includes our branching strategy and release management. We use git and GitHub to help us manage development.<br />
<br />
= Overview Diagram =<br />
[[File:Git_Workflow_-_WormBase4.png]]<br />
<br />
[https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing Editable version of the diagram]<br />
<br />
= Contributing =<br />
<br />
Whenever you begin work on a new issue you should create a new branch for it. Any new features should branch off <code>staging</code>. Once the feature is ready for testing, you can submit a pull request to <code>staging</code> for code review. Feature branches aren't necessarily branches in the main repository - they can in the main WormBase repository, or on a developer's fork. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Branch_stratgey Read more on our branching strategy]<br />
<br />
git checkout -b myFeature staging<br />
<br />
Now you can make your changes and commit some code. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Commit_messages Read more on commit messages]<br />
git add /PATH/TO/UPDATED/FILE<br />
git commit -m "Descriptive commit message"<br />
<br />
When you're ready, you can push your branch to GitHub<br />
<br />
git push origin myFeature<br />
<br />
Continue making changes until your code is ready for a code review. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Is_my_code_ready_for_review.3F Is my code ready for review?]<br />
<br />
When your code is ready, go to GitHub and create a Pull Request. [http://nathanhoad.net/git-workflow-forks-remotes-and-pull-requests More info on Pull Requests.]<br />
<br />
# Go to the repository where you pushed your changes<br />
# Switch to your branch (myFeature)<br />
# Click the green '''Compare & review''' button<br />
# After reviewing all the changes, click on '''Create pull request''' in the header to send the pull request<br />
# In the description, write a short summary of the issues (along with a link to the issue) and changes made along with some links for testing [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#What_info_should_I_include_in_a_Pull_Request.3F What info should I include in a Pull Request?]<br />
<br />
Wait for another member of the web development team to review and merge your pull request. If more changes are requested, you can push more commits to the same branch and it will be added to the pull request.<br />
<br />
Once your pull request is merged, locally bring in the changes and delete your issue branch<br />
git checkout staging<br />
git pull<br />
git branch -d myFeature<br />
<br />
Go to the original github issue:<br />
# Add the '''Under testing''' label to your issue<br />
# Comment on the issue to notify all involved that it is ready for testing. Add links for testing for the ease of testers.<br />
# Another member of the WormBase group will close the issue once they have tested it<br />
<br />
Note: You can view all merged pull requests using this link: https://github.com/WormBase/website/pulls?q=is%3Apr+is%3Amerged<br />
== Is my code ready for review? == <br />
<br />
Before you send a Pull Request, please make sure you have completed the following:<br />
<br />
* Written tests (API tests or REST tests) demonstrating the problem in the issue. [http://wiki.wormbase.org/index.php/Unit_Testing More info on testing]<br />
* Fix the problem (ie pass the tests)<br />
* Complete the issue as much as possible without curators seeing an example<br />
* Code style meeting the [http://wiki.wormbase.org/index.php/Coding_standards WormBase coding standards] (indentation, comments, no debug statements)<br />
<br />
== What info should I include in a Pull Request? ==<br />
<br />
To help your reviewer understand your code, please try to include the following in the Pull Request description<br />
<br />
* A link to the issue being addressed<br />
* Short summary of the problem<br />
* Some links to use for testing<br />
* Any other information that may be needed to testing (ie wormbase_local.conf changes, extra files needed, etc)<br />
<br />
== Commit messages ==<br />
git commit -m "COMMIT MESSAGE GOES HERE"<br />
<br />
Keep your commit message as descriptive as possible, reference any issues affected by the issue number (#YYY):<br />
This is a summary of my commit.<br />
* here is a breakdown of the different changes<br />
* mention github users (@tharris) when appropriate<br />
* related to #529<br />
* #945<br />
<br />
Here is a template originally written by Tim Pope at tpope.net:<br />
<pre><br />
Short (50 chars or less) summary of changes<br />
<br />
More detailed explanatory text, if necessary. Wrap it to about 72<br />
characters or so. In some contexts, the first line is treated as the<br />
subject of an email and the rest of the text as the body. The blank<br />
line separating the summary from the body is critical (unless you omit<br />
the body entirely); tools like rebase can get confused if you run the<br />
two together.<br />
<br />
Further paragraphs come after blank lines.<br />
<br />
- Bullet points are okay, too<br />
<br />
- Typically a hyphen or asterisk is used for the bullet, preceded by a<br />
single space, with blank lines in between, but conventions vary here<br />
</pre><br />
<br />
= Code Review =<br />
<br />
All changes must go through a code review before being merged to the staging branch. At WormBase, this is done using Pull Requests. All members of the core development team are expected to keep an eye on the open Pull Requests and reviewing the ones they are assigned.<br />
<br />
* Test out the pull request (check out the branch)<br />
* Take a quick look at the code (are there comments? anything obvious missing)<br />
* Run the tests written for this issue<br />
* Leave a comment on the PR if you notice anything that needs to be fixed<br />
* Merge the PR if you think it looks good<br />
** Begin by merging staging into the feature branch.<br />
** If there are conflicts, ask the owner of the PR to help resolve them.<br />
<br />
= Testing =<br />
All issues need to be tested and closed by at least one person who is not the developer who made the change. Ideally, it would be the curator asking for the feature/fix.<br />
<br />
'''If you would like to help test''':<br />
* Look at the [https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']. <br />
* All the changes for these issues are available for testing on [http://staging.wormbase.org staging.wormbase.org].<br />
* You can test out the changes and leave any feedback you have in the issue comments. <br />
* If you think this feature/fix is ready for production, you can '''close the issue'''.<br />
<br />
= Branch Strategy =<br />
We use branches to help with our release management, testing strategy, and helping with parallel development among the team.<br />
<br />
== Main branches ==<br />
Inside the <code>WormBase/website</code> repository, there are three main branches: <code>master</code>, <code>staging</code> and <code>production</code>.<br />
<br />
* <code>master</code>: current, stable code. All new changes brought into master have been tested on [http://staging.wormbase.org staging.wormbase.org] and approved by either the curator requesting the change, or the development lead.<br />
<br />
* <code>staging</code>: any features/changes ready for testing should be pushed to the <code>staging</code> branch. This code gets pushed nightly to [http://staging.wormbase.org staging.wormbase.org].<br />
<br />
* <code>production</code>: the code currently in production. Branched off of <code>master</code> at each release.<br />
<br />
== Feature branches ==<br />
Any new major features should branch off <code>staging</code>. Once the feature is ready for testing, it can be merged back into <code>staging</code>. These aren't necessarily branches in the main repository - can be local, or on a developer's fork.<br />
<br />
<br />
== Hotfixes ==<br />
If a major bugfix is needed in production, create a hotfix branch from production. When finished, the branch needs to be merged back into <code>production</code> and <code>staging</code><br />
<br />
=== Begining a fix ===<br />
git checkout -b hotfix-issXXX production<br />
<br />
Fix the bug and commit the fix in one or more commits. Reference the github issue:<br />
git commit -m "Severe production bug<br />
* search redirecting to home page<br />
* fix #XXX"<br />
<br />
=== Closing the fix ===<br />
The fix needs to be merged back to both <code>production</code> and <code>staging</code><br />
git checkout staging<br />
git merge hotfix-issXXX<br />
<br />
git checkout production<br />
git merge hotfix-issXXX<br />
<br />
= Development Timeline =<br />
<br />
See: [https://docs.google.com/document/d/1zIOm95tV9A14n9xnkPkMgiOTGcOIzx161y9UbDZvfW4/pub WormBase Release Workflow]<br />
<br />
= Release Management =<br />
When production is ready to updated for release WSXXX:<br />
<br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:master...staging pull request from staging to master]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:production...master pull request from master to production]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Tag production branch with appropriate release name.<br />
<br />
<br />
git checkout production<br />
git tag -a WSXXX<br />
<br />
= Links =<br />
* [http://staging.wormbase.org staging site for testing]<br />
* [https://github.com/WormBase/website github repository]<br />
* [https://github.com/WormBase/website/issues github issue tracker]<br />
* [https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing workflow diagram]<br />
<br />
[[Category:Development General (Web Dev)]]<br />
[[Category:Getting Started (Web Dev)]]</div>Acabunochttps://wiki.wormbase.org/index.php?title=Development_workflow_-_webdev&diff=24303Development workflow - webdev2014-07-29T19:20:37Z<p>Acabunoc: /* Contributing */</p>
<hr />
<div>This page describes the development model used by the web development team at WormBase using git as our version control system. This includes our branching strategy and release management. We use git and GitHub to help us manage development.<br />
<br />
= Overview Diagram =<br />
[[File:Git_Workflow_-_WormBase4.png]]<br />
<br />
[https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing Editable version of the diagram]<br />
<br />
= Contributing =<br />
<br />
Whenever you begin work on a new issue you should create a new branch for it. Any new features should branch off <code>staging</code>. Once the feature is ready for testing, you can submit a pull request to <code>staging</code> for code review. Feature branches aren't necessarily branches in the main repository - they can in the main WormBase repository, or on a developer's fork. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Branch_stratgey Read more on our branching strategy]<br />
<br />
git checkout -b myFeature staging<br />
<br />
Now you can make your changes and commit some code. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Commit_messages Read more on commit messages]<br />
git add /PATH/TO/UPDATED/FILE<br />
git commit -m "Descriptive commit message"<br />
<br />
When you're ready, you can push your branch to GitHub<br />
<br />
git push origin myFeature<br />
<br />
Continue making changes until your code is ready for a code review. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Is_my_code_ready_for_review.3F Is my code ready for review?]<br />
<br />
When your code is ready, go to GitHub and create a Pull Request. [http://nathanhoad.net/git-workflow-forks-remotes-and-pull-requests More info on Pull Requests.]<br />
<br />
# Go to the repository where you pushed your changes<br />
# Switch to your branch (myFeature)<br />
# Click the green '''Compare & review''' button<br />
# After reviewing all the changes, click on '''Create pull request''' in the header to send the pull request<br />
# In the description, write a short summary of the issues (along with a link to the issue) and changes made along with some links for testing [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#What_info_should_I_include_in_a_Pull_Request.3F What info should I include in a Pull Request?]<br />
<br />
Wait for another member of the web development team to review and merge your pull request. If more changes are requested, you can push more commits to the same branch and it will be added to the pull request.<br />
<br />
Once your pull request is merged, locally bring in the changes and delete your issue branch<br />
git checkout staging<br />
git pull<br />
git branch -d myFeature<br />
<br />
Go to the original github issue:<br />
# Add the '''Under testing''' label to your issue<br />
# Comment on the issue to notify all involved that it is ready for testing. Add links for testing for the ease of testers.<br />
# Another member of the WormBase group will close the issue once they have tested it<br />
<br />
Note: You can view all merged pull requests using this link: https://github.com/WormBase/website/pulls?q=is%3Apr+is%3Amerged<br />
== Is my code ready for review? == <br />
<br />
Before you send a Pull Request, please make sure you have completed the following:<br />
<br />
* Written tests (API tests or REST tests) demonstrating the problem in the issue. [http://wiki.wormbase.org/index.php/Unit_Testing More info on testing]<br />
* Fix the problem (ie pass the tests)<br />
* Complete the issue as much as possible without curators seeing an example<br />
* Code style meeting the [http://wiki.wormbase.org/index.php/Coding_standards WormBase coding standards] (indentation, comments, no debug statements)<br />
<br />
== What info should I include in a Pull Request? ==<br />
<br />
To help your reviewer understand your code, please try to include the following in the Pull Request description<br />
<br />
* A link to the issue being addressed<br />
* Short summary of the problem<br />
* Some links to use for testing<br />
* Any other information that may be needed to testing (ie wormbase_local.conf changes, extra files needed, etc)<br />
<br />
== Commit messages ==<br />
git commit -m "COMMIT MESSAGE GOES HERE"<br />
<br />
Keep your commit message as descriptive as possible, reference any issues affected by the issue number (#YYY):<br />
This is a summary of my commit.<br />
* here is a breakdown of the different changes<br />
* mention github users (@tharris) when appropriate<br />
* related to #529<br />
* #945<br />
<br />
Here is a template originally written by Tim Pope at tpope.net:<br />
<pre><br />
Short (50 chars or less) summary of changes<br />
<br />
More detailed explanatory text, if necessary. Wrap it to about 72<br />
characters or so. In some contexts, the first line is treated as the<br />
subject of an email and the rest of the text as the body. The blank<br />
line separating the summary from the body is critical (unless you omit<br />
the body entirely); tools like rebase can get confused if you run the<br />
two together.<br />
<br />
Further paragraphs come after blank lines.<br />
<br />
- Bullet points are okay, too<br />
<br />
- Typically a hyphen or asterisk is used for the bullet, preceded by a<br />
single space, with blank lines in between, but conventions vary here<br />
</pre><br />
<br />
= Code Review =<br />
<br />
All changes must go through a code review before being merged to the staging branch. At WormBase, this is done using Pull Requests. All members of the core development team are expected to keep an eye on the open Pull Requests and reviewing the ones they are most familiar with. Pull requests waiting for review should be left untouched for longer than two days after being assigned. <br />
<br />
* Test out the pull request (check out the branch)<br />
* Take a quick look at the code (are there comments? anything obvious missing)<br />
* Leave a comment on the PR if you notice anything that needs to be fixed<br />
* Merge the PR if you think it looks good<br />
<br />
= Testing =<br />
All issues need to be tested and closed by at least one person who is not the developer who made the change. Ideally, it would be the curator asking for the feature/fix.<br />
<br />
'''If you would like to help test''':<br />
* Look at the [https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']. <br />
* All the changes for these issues are available for testing on [http://staging.wormbase.org staging.wormbase.org].<br />
* You can test out the changes and leave any feedback you have in the issue comments. <br />
* If you think this feature/fix is ready for production, you can '''close the issue'''.<br />
<br />
= Branch Strategy =<br />
We use branches to help with our release management, testing strategy, and helping with parallel development among the team.<br />
<br />
== Main branches ==<br />
Inside the <code>WormBase/website</code> repository, there are three main branches: <code>master</code>, <code>staging</code> and <code>production</code>.<br />
<br />
* <code>master</code>: current, stable code. All new changes brought into master have been tested on [http://staging.wormbase.org staging.wormbase.org] and approved by either the curator requesting the change, or the development lead.<br />
<br />
* <code>staging</code>: any features/changes ready for testing should be pushed to the <code>staging</code> branch. This code gets pushed nightly to [http://staging.wormbase.org staging.wormbase.org].<br />
<br />
* <code>production</code>: the code currently in production. Branched off of <code>master</code> at each release.<br />
<br />
== Feature branches ==<br />
Any new major features should branch off <code>staging</code>. Once the feature is ready for testing, it can be merged back into <code>staging</code>. These aren't necessarily branches in the main repository - can be local, or on a developer's fork.<br />
<br />
<br />
== Hotfixes ==<br />
If a major bugfix is needed in production, create a hotfix branch from production. When finished, the branch needs to be merged back into <code>production</code> and <code>staging</code><br />
<br />
=== Begining a fix ===<br />
git checkout -b hotfix-issXXX production<br />
<br />
Fix the bug and commit the fix in one or more commits. Reference the github issue:<br />
git commit -m "Severe production bug<br />
* search redirecting to home page<br />
* fix #XXX"<br />
<br />
=== Closing the fix ===<br />
The fix needs to be merged back to both <code>production</code> and <code>staging</code><br />
git checkout staging<br />
git merge hotfix-issXXX<br />
<br />
git checkout production<br />
git merge hotfix-issXXX<br />
<br />
= Development Timeline =<br />
<br />
See: [https://docs.google.com/document/d/1zIOm95tV9A14n9xnkPkMgiOTGcOIzx161y9UbDZvfW4/pub WormBase Release Workflow]<br />
<br />
= Release Management =<br />
When production is ready to updated for release WSXXX:<br />
<br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:master...staging pull request from staging to master]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:production...master pull request from master to production]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Tag production branch with appropriate release name.<br />
<br />
<br />
git checkout production<br />
git tag -a WSXXX<br />
<br />
= Links =<br />
* [http://staging.wormbase.org staging site for testing]<br />
* [https://github.com/WormBase/website github repository]<br />
* [https://github.com/WormBase/website/issues github issue tracker]<br />
* [https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing workflow diagram]<br />
<br />
[[Category:Development General (Web Dev)]]<br />
[[Category:Getting Started (Web Dev)]]</div>Acabunochttps://wiki.wormbase.org/index.php?title=Development_workflow_-_webdev&diff=24302Development workflow - webdev2014-07-29T19:14:36Z<p>Acabunoc: /* Commit messages */</p>
<hr />
<div>This page describes the development model used by the web development team at WormBase using git as our version control system. This includes our branching strategy and release management. We use git and GitHub to help us manage development.<br />
<br />
= Overview Diagram =<br />
[[File:Git_Workflow_-_WormBase4.png]]<br />
<br />
[https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing Editable version of the diagram]<br />
<br />
= Contributing =<br />
<br />
Whenever you begin work on a new issue you should create a new branch for it. Any new features should branch off <code>staging</code>. Once the feature is ready for testing, you can submit a pull request to <code>staging</code> for code review. Feature branches aren't necessarily branches in the main repository - they can in the main WormBase repository, or on a developer's fork. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Branch_stratgey Read more on our branching strategy]<br />
<br />
git checkout -b myFeature staging<br />
<br />
Now you can make your changes and commit some code. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Commit_messages Read more on commit messages]<br />
git add /PATH/TO/UPDATED/FILE<br />
git commit -m "Descriptive commit message"<br />
<br />
When you're ready, you can push your branch to GitHub<br />
<br />
git push origin myFeature<br />
<br />
Continue making changes until your code is ready for a code review. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Is_my_code_ready_for_review.3F Is my code ready for review?]<br />
<br />
When your code is ready, go to GitHub and create a Pull Request. [http://nathanhoad.net/git-workflow-forks-remotes-and-pull-requests More info on Pull Requests.]<br />
<br />
# Go to the repository where you pushed your changes<br />
# Switch to your branch (myFeature)<br />
# Click the green '''Compare & review''' button<br />
# After reviewing all the changes, click on '''Create pull request''' in the header to send the pull request<br />
# In the description, write a short summary of the issues (along with a link to the issue) and changes made along with some links for testing [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#What_info_should_I_include_in_a_Pull_Request.3F What info should I include in a Pull Request?]<br />
<br />
Wait for another member of the web development team to review and merge your pull request. If more changes are requested, you can push more commits to the same branch and it will be added to the pull request.<br />
<br />
Once your pull request is merged, locally bring in the changes and delete your issue branch<br />
git checkout staging<br />
git pull<br />
git branch -d myFeature<br />
<br />
Go to the original github issue:<br />
# Add the '''Under testing''' label to your issue<br />
# Comment on the issue to notify all involved that it is ready for testing. Add links for testing for the ease of testers.<br />
# Another member of the WormBase group will close the issue once they have tested it<br />
<br />
== Is my code ready for review? == <br />
<br />
Before you send a Pull Request, please make sure you have completed the following:<br />
<br />
* Written tests (API tests or REST tests) demonstrating the problem in the issue. [http://wiki.wormbase.org/index.php/Unit_Testing More info on testing]<br />
* Fix the problem (ie pass the tests)<br />
* Complete the issue as much as possible without curators seeing an example<br />
* Code style meeting the [http://wiki.wormbase.org/index.php/Coding_standards WormBase coding standards] (indentation, comments, no debug statements)<br />
<br />
== What info should I include in a Pull Request? ==<br />
<br />
To help your reviewer understand your code, please try to include the following in the Pull Request description<br />
<br />
* A link to the issue being addressed<br />
* Short summary of the problem<br />
* Some links to use for testing<br />
* Any other information that may be needed to testing (ie wormbase_local.conf changes, extra files needed, etc)<br />
<br />
== Commit messages ==<br />
git commit -m "COMMIT MESSAGE GOES HERE"<br />
<br />
Keep your commit message as descriptive as possible, reference any issues affected by the issue number (#YYY):<br />
This is a summary of my commit.<br />
* here is a breakdown of the different changes<br />
* mention github users (@tharris) when appropriate<br />
* related to #529<br />
* #945<br />
<br />
Here is a template originally written by Tim Pope at tpope.net:<br />
<pre><br />
Short (50 chars or less) summary of changes<br />
<br />
More detailed explanatory text, if necessary. Wrap it to about 72<br />
characters or so. In some contexts, the first line is treated as the<br />
subject of an email and the rest of the text as the body. The blank<br />
line separating the summary from the body is critical (unless you omit<br />
the body entirely); tools like rebase can get confused if you run the<br />
two together.<br />
<br />
Further paragraphs come after blank lines.<br />
<br />
- Bullet points are okay, too<br />
<br />
- Typically a hyphen or asterisk is used for the bullet, preceded by a<br />
single space, with blank lines in between, but conventions vary here<br />
</pre><br />
<br />
= Code Review =<br />
<br />
All changes must go through a code review before being merged to the staging branch. At WormBase, this is done using Pull Requests. All members of the core development team are expected to keep an eye on the open Pull Requests and reviewing the ones they are most familiar with. Pull requests waiting for review should be left untouched for longer than two days after being assigned. <br />
<br />
* Test out the pull request (check out the branch)<br />
* Take a quick look at the code (are there comments? anything obvious missing)<br />
* Leave a comment on the PR if you notice anything that needs to be fixed<br />
* Merge the PR if you think it looks good<br />
<br />
= Testing =<br />
All issues need to be tested and closed by at least one person who is not the developer who made the change. Ideally, it would be the curator asking for the feature/fix.<br />
<br />
'''If you would like to help test''':<br />
* Look at the [https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']. <br />
* All the changes for these issues are available for testing on [http://staging.wormbase.org staging.wormbase.org].<br />
* You can test out the changes and leave any feedback you have in the issue comments. <br />
* If you think this feature/fix is ready for production, you can '''close the issue'''.<br />
<br />
= Branch Strategy =<br />
We use branches to help with our release management, testing strategy, and helping with parallel development among the team.<br />
<br />
== Main branches ==<br />
Inside the <code>WormBase/website</code> repository, there are three main branches: <code>master</code>, <code>staging</code> and <code>production</code>.<br />
<br />
* <code>master</code>: current, stable code. All new changes brought into master have been tested on [http://staging.wormbase.org staging.wormbase.org] and approved by either the curator requesting the change, or the development lead.<br />
<br />
* <code>staging</code>: any features/changes ready for testing should be pushed to the <code>staging</code> branch. This code gets pushed nightly to [http://staging.wormbase.org staging.wormbase.org].<br />
<br />
* <code>production</code>: the code currently in production. Branched off of <code>master</code> at each release.<br />
<br />
== Feature branches ==<br />
Any new major features should branch off <code>staging</code>. Once the feature is ready for testing, it can be merged back into <code>staging</code>. These aren't necessarily branches in the main repository - can be local, or on a developer's fork.<br />
<br />
<br />
== Hotfixes ==<br />
If a major bugfix is needed in production, create a hotfix branch from production. When finished, the branch needs to be merged back into <code>production</code> and <code>staging</code><br />
<br />
=== Begining a fix ===<br />
git checkout -b hotfix-issXXX production<br />
<br />
Fix the bug and commit the fix in one or more commits. Reference the github issue:<br />
git commit -m "Severe production bug<br />
* search redirecting to home page<br />
* fix #XXX"<br />
<br />
=== Closing the fix ===<br />
The fix needs to be merged back to both <code>production</code> and <code>staging</code><br />
git checkout staging<br />
git merge hotfix-issXXX<br />
<br />
git checkout production<br />
git merge hotfix-issXXX<br />
<br />
= Development Timeline =<br />
<br />
See: [https://docs.google.com/document/d/1zIOm95tV9A14n9xnkPkMgiOTGcOIzx161y9UbDZvfW4/pub WormBase Release Workflow]<br />
<br />
= Release Management =<br />
When production is ready to updated for release WSXXX:<br />
<br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:master...staging pull request from staging to master]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:production...master pull request from master to production]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Tag production branch with appropriate release name.<br />
<br />
<br />
git checkout production<br />
git tag -a WSXXX<br />
<br />
= Links =<br />
* [http://staging.wormbase.org staging site for testing]<br />
* [https://github.com/WormBase/website github repository]<br />
* [https://github.com/WormBase/website/issues github issue tracker]<br />
* [https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing workflow diagram]<br />
<br />
[[Category:Development General (Web Dev)]]<br />
[[Category:Getting Started (Web Dev)]]</div>Acabunochttps://wiki.wormbase.org/index.php?title=Development_workflow_-_webdev&diff=24301Development workflow - webdev2014-07-29T19:13:04Z<p>Acabunoc: /* Commit messages */</p>
<hr />
<div>This page describes the development model used by the web development team at WormBase using git as our version control system. This includes our branching strategy and release management. We use git and GitHub to help us manage development.<br />
<br />
= Overview Diagram =<br />
[[File:Git_Workflow_-_WormBase4.png]]<br />
<br />
[https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing Editable version of the diagram]<br />
<br />
= Contributing =<br />
<br />
Whenever you begin work on a new issue you should create a new branch for it. Any new features should branch off <code>staging</code>. Once the feature is ready for testing, you can submit a pull request to <code>staging</code> for code review. Feature branches aren't necessarily branches in the main repository - they can in the main WormBase repository, or on a developer's fork. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Branch_stratgey Read more on our branching strategy]<br />
<br />
git checkout -b myFeature staging<br />
<br />
Now you can make your changes and commit some code. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Commit_messages Read more on commit messages]<br />
git add /PATH/TO/UPDATED/FILE<br />
git commit -m "Descriptive commit message"<br />
<br />
When you're ready, you can push your branch to GitHub<br />
<br />
git push origin myFeature<br />
<br />
Continue making changes until your code is ready for a code review. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Is_my_code_ready_for_review.3F Is my code ready for review?]<br />
<br />
When your code is ready, go to GitHub and create a Pull Request. [http://nathanhoad.net/git-workflow-forks-remotes-and-pull-requests More info on Pull Requests.]<br />
<br />
# Go to the repository where you pushed your changes<br />
# Switch to your branch (myFeature)<br />
# Click the green '''Compare & review''' button<br />
# After reviewing all the changes, click on '''Create pull request''' in the header to send the pull request<br />
# In the description, write a short summary of the issues (along with a link to the issue) and changes made along with some links for testing [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#What_info_should_I_include_in_a_Pull_Request.3F What info should I include in a Pull Request?]<br />
<br />
Wait for another member of the web development team to review and merge your pull request. If more changes are requested, you can push more commits to the same branch and it will be added to the pull request.<br />
<br />
Once your pull request is merged, locally bring in the changes and delete your issue branch<br />
git checkout staging<br />
git pull<br />
git branch -d myFeature<br />
<br />
Go to the original github issue:<br />
# Add the '''Under testing''' label to your issue<br />
# Comment on the issue to notify all involved that it is ready for testing. Add links for testing for the ease of testers.<br />
# Another member of the WormBase group will close the issue once they have tested it<br />
<br />
== Is my code ready for review? == <br />
<br />
Before you send a Pull Request, please make sure you have completed the following:<br />
<br />
* Written tests (API tests or REST tests) demonstrating the problem in the issue. [http://wiki.wormbase.org/index.php/Unit_Testing More info on testing]<br />
* Fix the problem (ie pass the tests)<br />
* Complete the issue as much as possible without curators seeing an example<br />
* Code style meeting the [http://wiki.wormbase.org/index.php/Coding_standards WormBase coding standards] (indentation, comments, no debug statements)<br />
<br />
== What info should I include in a Pull Request? ==<br />
<br />
To help your reviewer understand your code, please try to include the following in the Pull Request description<br />
<br />
* A link to the issue being addressed<br />
* Short summary of the problem<br />
* Some links to use for testing<br />
* Any other information that may be needed to testing (ie wormbase_local.conf changes, extra files needed, etc)<br />
<br />
== Commit messages ==<br />
git commit -m "COMMIT MESSAGE GOES HERE"<br />
<br />
Keep your commit message as descriptive as possible, reference any issues affected:<br />
This is a summary of my commit.<br />
* here is a breakdown of the different changes<br />
* mention github users (@tharris) when appropriate<br />
* related to #YYY<br />
* #XXX<br />
<br />
Here is a template originally written by Tim Pope at tpope.net:<br />
<pre><br />
Short (50 chars or less) summary of changes<br />
<br />
More detailed explanatory text, if necessary. Wrap it to about 72<br />
characters or so. In some contexts, the first line is treated as the<br />
subject of an email and the rest of the text as the body. The blank<br />
line separating the summary from the body is critical (unless you omit<br />
the body entirely); tools like rebase can get confused if you run the<br />
two together.<br />
<br />
Further paragraphs come after blank lines.<br />
<br />
- Bullet points are okay, too<br />
<br />
- Typically a hyphen or asterisk is used for the bullet, preceded by a<br />
single space, with blank lines in between, but conventions vary here<br />
</pre><br />
<br />
= Code Review =<br />
<br />
All changes must go through a code review before being merged to the staging branch. At WormBase, this is done using Pull Requests. All members of the core development team are expected to keep an eye on the open Pull Requests and reviewing the ones they are most familiar with. Pull requests waiting for review should be left untouched for longer than two days after being assigned. <br />
<br />
* Test out the pull request (check out the branch)<br />
* Take a quick look at the code (are there comments? anything obvious missing)<br />
* Leave a comment on the PR if you notice anything that needs to be fixed<br />
* Merge the PR if you think it looks good<br />
<br />
= Testing =<br />
All issues need to be tested and closed by at least one person who is not the developer who made the change. Ideally, it would be the curator asking for the feature/fix.<br />
<br />
'''If you would like to help test''':<br />
* Look at the [https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']. <br />
* All the changes for these issues are available for testing on [http://staging.wormbase.org staging.wormbase.org].<br />
* You can test out the changes and leave any feedback you have in the issue comments. <br />
* If you think this feature/fix is ready for production, you can '''close the issue'''.<br />
<br />
= Branch Strategy =<br />
We use branches to help with our release management, testing strategy, and helping with parallel development among the team.<br />
<br />
== Main branches ==<br />
Inside the <code>WormBase/website</code> repository, there are three main branches: <code>master</code>, <code>staging</code> and <code>production</code>.<br />
<br />
* <code>master</code>: current, stable code. All new changes brought into master have been tested on [http://staging.wormbase.org staging.wormbase.org] and approved by either the curator requesting the change, or the development lead.<br />
<br />
* <code>staging</code>: any features/changes ready for testing should be pushed to the <code>staging</code> branch. This code gets pushed nightly to [http://staging.wormbase.org staging.wormbase.org].<br />
<br />
* <code>production</code>: the code currently in production. Branched off of <code>master</code> at each release.<br />
<br />
== Feature branches ==<br />
Any new major features should branch off <code>staging</code>. Once the feature is ready for testing, it can be merged back into <code>staging</code>. These aren't necessarily branches in the main repository - can be local, or on a developer's fork.<br />
<br />
<br />
== Hotfixes ==<br />
If a major bugfix is needed in production, create a hotfix branch from production. When finished, the branch needs to be merged back into <code>production</code> and <code>staging</code><br />
<br />
=== Begining a fix ===<br />
git checkout -b hotfix-issXXX production<br />
<br />
Fix the bug and commit the fix in one or more commits. Reference the github issue:<br />
git commit -m "Severe production bug<br />
* search redirecting to home page<br />
* fix #XXX"<br />
<br />
=== Closing the fix ===<br />
The fix needs to be merged back to both <code>production</code> and <code>staging</code><br />
git checkout staging<br />
git merge hotfix-issXXX<br />
<br />
git checkout production<br />
git merge hotfix-issXXX<br />
<br />
= Development Timeline =<br />
<br />
See: [https://docs.google.com/document/d/1zIOm95tV9A14n9xnkPkMgiOTGcOIzx161y9UbDZvfW4/pub WormBase Release Workflow]<br />
<br />
= Release Management =<br />
When production is ready to updated for release WSXXX:<br />
<br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:master...staging pull request from staging to master]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:production...master pull request from master to production]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Tag production branch with appropriate release name.<br />
<br />
<br />
git checkout production<br />
git tag -a WSXXX<br />
<br />
= Links =<br />
* [http://staging.wormbase.org staging site for testing]<br />
* [https://github.com/WormBase/website github repository]<br />
* [https://github.com/WormBase/website/issues github issue tracker]<br />
* [https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing workflow diagram]<br />
<br />
[[Category:Development General (Web Dev)]]<br />
[[Category:Getting Started (Web Dev)]]</div>Acabunochttps://wiki.wormbase.org/index.php?title=Development_workflow_-_webdev&diff=24300Development workflow - webdev2014-07-29T19:10:46Z<p>Acabunoc: /* Contributing */</p>
<hr />
<div>This page describes the development model used by the web development team at WormBase using git as our version control system. This includes our branching strategy and release management. We use git and GitHub to help us manage development.<br />
<br />
= Overview Diagram =<br />
[[File:Git_Workflow_-_WormBase4.png]]<br />
<br />
[https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing Editable version of the diagram]<br />
<br />
= Contributing =<br />
<br />
Whenever you begin work on a new issue you should create a new branch for it. Any new features should branch off <code>staging</code>. Once the feature is ready for testing, you can submit a pull request to <code>staging</code> for code review. Feature branches aren't necessarily branches in the main repository - they can in the main WormBase repository, or on a developer's fork. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Branch_stratgey Read more on our branching strategy]<br />
<br />
git checkout -b myFeature staging<br />
<br />
Now you can make your changes and commit some code. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Commit_messages Read more on commit messages]<br />
git add /PATH/TO/UPDATED/FILE<br />
git commit -m "Descriptive commit message"<br />
<br />
When you're ready, you can push your branch to GitHub<br />
<br />
git push origin myFeature<br />
<br />
Continue making changes until your code is ready for a code review. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Is_my_code_ready_for_review.3F Is my code ready for review?]<br />
<br />
When your code is ready, go to GitHub and create a Pull Request. [http://nathanhoad.net/git-workflow-forks-remotes-and-pull-requests More info on Pull Requests.]<br />
<br />
# Go to the repository where you pushed your changes<br />
# Switch to your branch (myFeature)<br />
# Click the green '''Compare & review''' button<br />
# After reviewing all the changes, click on '''Create pull request''' in the header to send the pull request<br />
# In the description, write a short summary of the issues (along with a link to the issue) and changes made along with some links for testing [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#What_info_should_I_include_in_a_Pull_Request.3F What info should I include in a Pull Request?]<br />
<br />
Wait for another member of the web development team to review and merge your pull request. If more changes are requested, you can push more commits to the same branch and it will be added to the pull request.<br />
<br />
Once your pull request is merged, locally bring in the changes and delete your issue branch<br />
git checkout staging<br />
git pull<br />
git branch -d myFeature<br />
<br />
Go to the original github issue:<br />
# Add the '''Under testing''' label to your issue<br />
# Comment on the issue to notify all involved that it is ready for testing. Add links for testing for the ease of testers.<br />
# Another member of the WormBase group will close the issue once they have tested it<br />
<br />
== Is my code ready for review? == <br />
<br />
Before you send a Pull Request, please make sure you have completed the following:<br />
<br />
* Written tests (API tests or REST tests) demonstrating the problem in the issue. [http://wiki.wormbase.org/index.php/Unit_Testing More info on testing]<br />
* Fix the problem (ie pass the tests)<br />
* Complete the issue as much as possible without curators seeing an example<br />
* Code style meeting the [http://wiki.wormbase.org/index.php/Coding_standards WormBase coding standards] (indentation, comments, no debug statements)<br />
<br />
== What info should I include in a Pull Request? ==<br />
<br />
To help your reviewer understand your code, please try to include the following in the Pull Request description<br />
<br />
* A link to the issue being addressed<br />
* Short summary of the problem<br />
* Some links to use for testing<br />
* Any other information that may be needed to testing (ie wormbase_local.conf changes, extra files needed, etc)<br />
<br />
== Commit messages ==<br />
git commit -m "COMMIT MESSAGE GOES HERE"<br />
<br />
Keep your commit message as descriptive as possible, reference any issues affected, close any this resolves:<br />
This is a summary of my commit.<br />
* here is a breakdown of the different changes<br />
* mention github users (@tharris) when appropriate<br />
* related to #YYY<br />
* fix #XXX<br />
<br />
Here is a template originally written by Tim Pope at tpope.net:<br />
<pre><br />
Short (50 chars or less) summary of changes<br />
<br />
More detailed explanatory text, if necessary. Wrap it to about 72<br />
characters or so. In some contexts, the first line is treated as the<br />
subject of an email and the rest of the text as the body. The blank<br />
line separating the summary from the body is critical (unless you omit<br />
the body entirely); tools like rebase can get confused if you run the<br />
two together.<br />
<br />
Further paragraphs come after blank lines.<br />
<br />
- Bullet points are okay, too<br />
<br />
- Typically a hyphen or asterisk is used for the bullet, preceded by a<br />
single space, with blank lines in between, but conventions vary here<br />
</pre><br />
<br />
= Code Review =<br />
<br />
All changes must go through a code review before being merged to the staging branch. At WormBase, this is done using Pull Requests. All members of the core development team are expected to keep an eye on the open Pull Requests and reviewing the ones they are most familiar with. Pull requests waiting for review should be left untouched for longer than two days after being assigned. <br />
<br />
* Test out the pull request (check out the branch)<br />
* Take a quick look at the code (are there comments? anything obvious missing)<br />
* Leave a comment on the PR if you notice anything that needs to be fixed<br />
* Merge the PR if you think it looks good<br />
<br />
= Testing =<br />
All issues need to be tested and closed by at least one person who is not the developer who made the change. Ideally, it would be the curator asking for the feature/fix.<br />
<br />
'''If you would like to help test''':<br />
* Look at the [https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']. <br />
* All the changes for these issues are available for testing on [http://staging.wormbase.org staging.wormbase.org].<br />
* You can test out the changes and leave any feedback you have in the issue comments. <br />
* If you think this feature/fix is ready for production, you can '''close the issue'''.<br />
<br />
= Branch Strategy =<br />
We use branches to help with our release management, testing strategy, and helping with parallel development among the team.<br />
<br />
== Main branches ==<br />
Inside the <code>WormBase/website</code> repository, there are three main branches: <code>master</code>, <code>staging</code> and <code>production</code>.<br />
<br />
* <code>master</code>: current, stable code. All new changes brought into master have been tested on [http://staging.wormbase.org staging.wormbase.org] and approved by either the curator requesting the change, or the development lead.<br />
<br />
* <code>staging</code>: any features/changes ready for testing should be pushed to the <code>staging</code> branch. This code gets pushed nightly to [http://staging.wormbase.org staging.wormbase.org].<br />
<br />
* <code>production</code>: the code currently in production. Branched off of <code>master</code> at each release.<br />
<br />
== Feature branches ==<br />
Any new major features should branch off <code>staging</code>. Once the feature is ready for testing, it can be merged back into <code>staging</code>. These aren't necessarily branches in the main repository - can be local, or on a developer's fork.<br />
<br />
<br />
== Hotfixes ==<br />
If a major bugfix is needed in production, create a hotfix branch from production. When finished, the branch needs to be merged back into <code>production</code> and <code>staging</code><br />
<br />
=== Begining a fix ===<br />
git checkout -b hotfix-issXXX production<br />
<br />
Fix the bug and commit the fix in one or more commits. Reference the github issue:<br />
git commit -m "Severe production bug<br />
* search redirecting to home page<br />
* fix #XXX"<br />
<br />
=== Closing the fix ===<br />
The fix needs to be merged back to both <code>production</code> and <code>staging</code><br />
git checkout staging<br />
git merge hotfix-issXXX<br />
<br />
git checkout production<br />
git merge hotfix-issXXX<br />
<br />
= Development Timeline =<br />
<br />
See: [https://docs.google.com/document/d/1zIOm95tV9A14n9xnkPkMgiOTGcOIzx161y9UbDZvfW4/pub WormBase Release Workflow]<br />
<br />
= Release Management =<br />
When production is ready to updated for release WSXXX:<br />
<br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:master...staging pull request from staging to master]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:production...master pull request from master to production]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Tag production branch with appropriate release name.<br />
<br />
<br />
git checkout production<br />
git tag -a WSXXX<br />
<br />
= Links =<br />
* [http://staging.wormbase.org staging site for testing]<br />
* [https://github.com/WormBase/website github repository]<br />
* [https://github.com/WormBase/website/issues github issue tracker]<br />
* [https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing workflow diagram]<br />
<br />
[[Category:Development General (Web Dev)]]<br />
[[Category:Getting Started (Web Dev)]]</div>Acabunochttps://wiki.wormbase.org/index.php?title=Development_workflow_-_webdev&diff=24299Development workflow - webdev2014-07-29T19:08:12Z<p>Acabunoc: /* Contributing */</p>
<hr />
<div>This page describes the development model used by the web development team at WormBase using git as our version control system. This includes our branching strategy and release management. We use git and GitHub to help us manage development.<br />
<br />
= Overview Diagram =<br />
[[File:Git_Workflow_-_WormBase4.png]]<br />
<br />
[https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing Editable version of the diagram]<br />
<br />
= Contributing =<br />
<br />
Whenever you begin work on a new issue you should create a new branch for it. Any new features should branch off <code>staging</code>. Once the feature is ready for testing, you can submit a pull request to <code>staging</code> for code review. Feature branches aren't necessarily branches in the main repository - they can in the main WormBase repository, or on a developer's fork. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Branch_stratgey Read more on our branching strategy]<br />
<br />
git checkout -b myFeature staging<br />
<br />
Now you can make your changes and commit some code. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Commit_messages Read more on commit messages]<br />
git add /PATH/TO/UPDATED/FILE<br />
git commit -m "Descriptive commit message"<br />
<br />
When you're ready, you can push your branch to GitHub<br />
<br />
git push origin myFeature<br />
<br />
Continue making changes until your code is ready for a code review. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Is_my_code_ready_for_review.3F Is my code ready for review?]<br />
<br />
When your code is ready, go to GitHub and create a Pull Request. [http://nathanhoad.net/git-workflow-forks-remotes-and-pull-requests More info on Pull Requests.]<br />
<br />
# Go to the repository where you pushed your changes<br />
# Switch to your branch (myFeature)<br />
# Click the green '''Compare & review''' button<br />
# After reviewing all the changes, click on '''Create pull request''' in the header to send the pull request<br />
# In the description, write a short summary of the issues and changes made along with some links for testing [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#What_info_should_I_include_in_a_Pull_Request.3F What info should I include in a Pull Request?]<br />
<br />
Wait for another member of the web development team to review and merge your pull request. If more changes are requested, you can push more commits to the same branch and it will be added to the pull request.<br />
<br />
Once your pull request is merged, locally bring in the changes and delete your issue branch<br />
git checkout staging<br />
git pull<br />
git branch -d myFeature<br />
<br />
Go to the original github issue:<br />
# Add the '''Under testing''' label to your issue<br />
# Comment on the issue to notify all involved that it is ready for testing. Add links for testing for the ease of testers.<br />
# Another member of the WormBase group will close the issue once they have tested it<br />
<br />
== Is my code ready for review? == <br />
<br />
Before you send a Pull Request, please make sure you have completed the following:<br />
<br />
* Written tests (API tests or REST tests) demonstrating the problem in the issue. [http://wiki.wormbase.org/index.php/Unit_Testing More info on testing]<br />
* Fix the problem (ie pass the tests)<br />
* Complete the issue as much as possible without curators seeing an example<br />
* Code style meeting the [http://wiki.wormbase.org/index.php/Coding_standards WormBase coding standards] (indentation, comments, no debug statements)<br />
<br />
== What info should I include in a Pull Request? ==<br />
<br />
To help your reviewer understand your code, please try to include the following in the Pull Request description<br />
<br />
* A link to the issue being addressed<br />
* Short summary of the problem<br />
* Some links to use for testing<br />
* Any other information that may be needed to testing (ie wormbase_local.conf changes, extra files needed, etc)<br />
<br />
== Commit messages ==<br />
git commit -m "COMMIT MESSAGE GOES HERE"<br />
<br />
Keep your commit message as descriptive as possible, reference any issues affected, close any this resolves:<br />
This is a summary of my commit.<br />
* here is a breakdown of the different changes<br />
* mention github users (@tharris) when appropriate<br />
* related to #YYY<br />
* fix #XXX<br />
<br />
Here is a template originally written by Tim Pope at tpope.net:<br />
<pre><br />
Short (50 chars or less) summary of changes<br />
<br />
More detailed explanatory text, if necessary. Wrap it to about 72<br />
characters or so. In some contexts, the first line is treated as the<br />
subject of an email and the rest of the text as the body. The blank<br />
line separating the summary from the body is critical (unless you omit<br />
the body entirely); tools like rebase can get confused if you run the<br />
two together.<br />
<br />
Further paragraphs come after blank lines.<br />
<br />
- Bullet points are okay, too<br />
<br />
- Typically a hyphen or asterisk is used for the bullet, preceded by a<br />
single space, with blank lines in between, but conventions vary here<br />
</pre><br />
<br />
= Code Review =<br />
<br />
All changes must go through a code review before being merged to the staging branch. At WormBase, this is done using Pull Requests. All members of the core development team are expected to keep an eye on the open Pull Requests and reviewing the ones they are most familiar with. Pull requests waiting for review should be left untouched for longer than two days after being assigned. <br />
<br />
* Test out the pull request (check out the branch)<br />
* Take a quick look at the code (are there comments? anything obvious missing)<br />
* Leave a comment on the PR if you notice anything that needs to be fixed<br />
* Merge the PR if you think it looks good<br />
<br />
= Testing =<br />
All issues need to be tested and closed by at least one person who is not the developer who made the change. Ideally, it would be the curator asking for the feature/fix.<br />
<br />
'''If you would like to help test''':<br />
* Look at the [https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']. <br />
* All the changes for these issues are available for testing on [http://staging.wormbase.org staging.wormbase.org].<br />
* You can test out the changes and leave any feedback you have in the issue comments. <br />
* If you think this feature/fix is ready for production, you can '''close the issue'''.<br />
<br />
= Branch Strategy =<br />
We use branches to help with our release management, testing strategy, and helping with parallel development among the team.<br />
<br />
== Main branches ==<br />
Inside the <code>WormBase/website</code> repository, there are three main branches: <code>master</code>, <code>staging</code> and <code>production</code>.<br />
<br />
* <code>master</code>: current, stable code. All new changes brought into master have been tested on [http://staging.wormbase.org staging.wormbase.org] and approved by either the curator requesting the change, or the development lead.<br />
<br />
* <code>staging</code>: any features/changes ready for testing should be pushed to the <code>staging</code> branch. This code gets pushed nightly to [http://staging.wormbase.org staging.wormbase.org].<br />
<br />
* <code>production</code>: the code currently in production. Branched off of <code>master</code> at each release.<br />
<br />
== Feature branches ==<br />
Any new major features should branch off <code>staging</code>. Once the feature is ready for testing, it can be merged back into <code>staging</code>. These aren't necessarily branches in the main repository - can be local, or on a developer's fork.<br />
<br />
<br />
== Hotfixes ==<br />
If a major bugfix is needed in production, create a hotfix branch from production. When finished, the branch needs to be merged back into <code>production</code> and <code>staging</code><br />
<br />
=== Begining a fix ===<br />
git checkout -b hotfix-issXXX production<br />
<br />
Fix the bug and commit the fix in one or more commits. Reference the github issue:<br />
git commit -m "Severe production bug<br />
* search redirecting to home page<br />
* fix #XXX"<br />
<br />
=== Closing the fix ===<br />
The fix needs to be merged back to both <code>production</code> and <code>staging</code><br />
git checkout staging<br />
git merge hotfix-issXXX<br />
<br />
git checkout production<br />
git merge hotfix-issXXX<br />
<br />
= Development Timeline =<br />
<br />
See: [https://docs.google.com/document/d/1zIOm95tV9A14n9xnkPkMgiOTGcOIzx161y9UbDZvfW4/pub WormBase Release Workflow]<br />
<br />
= Release Management =<br />
When production is ready to updated for release WSXXX:<br />
<br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:master...staging pull request from staging to master]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:production...master pull request from master to production]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Tag production branch with appropriate release name.<br />
<br />
<br />
git checkout production<br />
git tag -a WSXXX<br />
<br />
= Links =<br />
* [http://staging.wormbase.org staging site for testing]<br />
* [https://github.com/WormBase/website github repository]<br />
* [https://github.com/WormBase/website/issues github issue tracker]<br />
* [https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing workflow diagram]<br />
<br />
[[Category:Development General (Web Dev)]]<br />
[[Category:Getting Started (Web Dev)]]</div>Acabunochttps://wiki.wormbase.org/index.php?title=Development_workflow_-_webdev&diff=24298Development workflow - webdev2014-07-29T19:07:28Z<p>Acabunoc: /* Contributing */</p>
<hr />
<div>This page describes the development model used by the web development team at WormBase using git as our version control system. This includes our branching strategy and release management. We use git and GitHub to help us manage development.<br />
<br />
= Overview Diagram =<br />
[[File:Git_Workflow_-_WormBase4.png]]<br />
<br />
[https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing Editable version of the diagram]<br />
<br />
= Contributing =<br />
<br />
Whenever you begin work on a new issue you should create a new branch for it. Any new features should branch off <code>staging</code>. Once the feature is ready for testing, you can submit a pull request to <code>staging</code> for code review. Feature branches aren't necessarily branches in the main repository - they can be local, or on a developer's fork. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Branch_stratgey Read more on our branching strategy]<br />
<br />
git checkout -b myFeature staging<br />
<br />
Now you can make your changes and commit some code. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Commit_messages Read more on commit messages]<br />
git add /PATH/TO/UPDATED/FILE<br />
git commit -m "Descriptive commit message"<br />
<br />
When you're ready, you can push your branch to GitHub<br />
<br />
git push origin myFeature<br />
<br />
Continue making changes until your code is ready for a code review. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Is_my_code_ready_for_review.3F Is my code ready for review?]<br />
<br />
When your code is ready, go to GitHub and create a Pull Request. [http://nathanhoad.net/git-workflow-forks-remotes-and-pull-requests More info on Pull Requests.]<br />
<br />
# Go to the repository where you pushed your changes<br />
# Switch to your branch (myFeature)<br />
# Click the green '''Compare & review''' button<br />
# After reviewing all the changes, click on '''Create pull request''' in the header to send the pull request<br />
# In the description, write a short summary of the issues and changes made along with some links for testing [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#What_info_should_I_include_in_a_Pull_Request.3F What info should I include in a Pull Request?]<br />
<br />
Wait for another member of the web development team to review and merge your pull request. If more changes are requested, you can push more commits to the same branch and it will be added to the pull request.<br />
<br />
Once your pull request is merged, locally bring in the changes and delete your issue branch<br />
git checkout staging<br />
git pull<br />
git branch -d myFeature<br />
<br />
Go to the original github issue:<br />
# Add the '''Under testing''' label to your issue<br />
# Comment on the issue to notify all involved that it is ready for testing. Add links for testing for the ease of testers.<br />
# Another member of the WormBase group will close the issue once they have tested it<br />
<br />
== Is my code ready for review? == <br />
<br />
Before you send a Pull Request, please make sure you have completed the following:<br />
<br />
* Written tests (API tests or REST tests) demonstrating the problem in the issue. [http://wiki.wormbase.org/index.php/Unit_Testing More info on testing]<br />
* Fix the problem (ie pass the tests)<br />
* Complete the issue as much as possible without curators seeing an example<br />
* Code style meeting the [http://wiki.wormbase.org/index.php/Coding_standards WormBase coding standards] (indentation, comments, no debug statements)<br />
<br />
== What info should I include in a Pull Request? ==<br />
<br />
To help your reviewer understand your code, please try to include the following in the Pull Request description<br />
<br />
* A link to the issue being addressed<br />
* Short summary of the problem<br />
* Some links to use for testing<br />
* Any other information that may be needed to testing (ie wormbase_local.conf changes, extra files needed, etc)<br />
<br />
== Commit messages ==<br />
git commit -m "COMMIT MESSAGE GOES HERE"<br />
<br />
Keep your commit message as descriptive as possible, reference any issues affected, close any this resolves:<br />
This is a summary of my commit.<br />
* here is a breakdown of the different changes<br />
* mention github users (@tharris) when appropriate<br />
* related to #YYY<br />
* fix #XXX<br />
<br />
Here is a template originally written by Tim Pope at tpope.net:<br />
<pre><br />
Short (50 chars or less) summary of changes<br />
<br />
More detailed explanatory text, if necessary. Wrap it to about 72<br />
characters or so. In some contexts, the first line is treated as the<br />
subject of an email and the rest of the text as the body. The blank<br />
line separating the summary from the body is critical (unless you omit<br />
the body entirely); tools like rebase can get confused if you run the<br />
two together.<br />
<br />
Further paragraphs come after blank lines.<br />
<br />
- Bullet points are okay, too<br />
<br />
- Typically a hyphen or asterisk is used for the bullet, preceded by a<br />
single space, with blank lines in between, but conventions vary here<br />
</pre><br />
<br />
= Code Review =<br />
<br />
All changes must go through a code review before being merged to the staging branch. At WormBase, this is done using Pull Requests. All members of the core development team are expected to keep an eye on the open Pull Requests and reviewing the ones they are most familiar with. Pull requests waiting for review should be left untouched for longer than two days after being assigned. <br />
<br />
* Test out the pull request (check out the branch)<br />
* Take a quick look at the code (are there comments? anything obvious missing)<br />
* Leave a comment on the PR if you notice anything that needs to be fixed<br />
* Merge the PR if you think it looks good<br />
<br />
= Testing =<br />
All issues need to be tested and closed by at least one person who is not the developer who made the change. Ideally, it would be the curator asking for the feature/fix.<br />
<br />
'''If you would like to help test''':<br />
* Look at the [https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']. <br />
* All the changes for these issues are available for testing on [http://staging.wormbase.org staging.wormbase.org].<br />
* You can test out the changes and leave any feedback you have in the issue comments. <br />
* If you think this feature/fix is ready for production, you can '''close the issue'''.<br />
<br />
= Branch Strategy =<br />
We use branches to help with our release management, testing strategy, and helping with parallel development among the team.<br />
<br />
== Main branches ==<br />
Inside the <code>WormBase/website</code> repository, there are three main branches: <code>master</code>, <code>staging</code> and <code>production</code>.<br />
<br />
* <code>master</code>: current, stable code. All new changes brought into master have been tested on [http://staging.wormbase.org staging.wormbase.org] and approved by either the curator requesting the change, or the development lead.<br />
<br />
* <code>staging</code>: any features/changes ready for testing should be pushed to the <code>staging</code> branch. This code gets pushed nightly to [http://staging.wormbase.org staging.wormbase.org].<br />
<br />
* <code>production</code>: the code currently in production. Branched off of <code>master</code> at each release.<br />
<br />
== Feature branches ==<br />
Any new major features should branch off <code>staging</code>. Once the feature is ready for testing, it can be merged back into <code>staging</code>. These aren't necessarily branches in the main repository - can be local, or on a developer's fork.<br />
<br />
<br />
== Hotfixes ==<br />
If a major bugfix is needed in production, create a hotfix branch from production. When finished, the branch needs to be merged back into <code>production</code> and <code>staging</code><br />
<br />
=== Begining a fix ===<br />
git checkout -b hotfix-issXXX production<br />
<br />
Fix the bug and commit the fix in one or more commits. Reference the github issue:<br />
git commit -m "Severe production bug<br />
* search redirecting to home page<br />
* fix #XXX"<br />
<br />
=== Closing the fix ===<br />
The fix needs to be merged back to both <code>production</code> and <code>staging</code><br />
git checkout staging<br />
git merge hotfix-issXXX<br />
<br />
git checkout production<br />
git merge hotfix-issXXX<br />
<br />
= Development Timeline =<br />
<br />
See: [https://docs.google.com/document/d/1zIOm95tV9A14n9xnkPkMgiOTGcOIzx161y9UbDZvfW4/pub WormBase Release Workflow]<br />
<br />
= Release Management =<br />
When production is ready to updated for release WSXXX:<br />
<br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:master...staging pull request from staging to master]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:production...master pull request from master to production]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Tag production branch with appropriate release name.<br />
<br />
<br />
git checkout production<br />
git tag -a WSXXX<br />
<br />
= Links =<br />
* [http://staging.wormbase.org staging site for testing]<br />
* [https://github.com/WormBase/website github repository]<br />
* [https://github.com/WormBase/website/issues github issue tracker]<br />
* [https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing workflow diagram]<br />
<br />
[[Category:Development General (Web Dev)]]<br />
[[Category:Getting Started (Web Dev)]]</div>Acabunochttps://wiki.wormbase.org/index.php?title=Development_workflow_-_webdev&diff=24297Development workflow - webdev2014-07-29T18:58:20Z<p>Acabunoc: /* Testing */</p>
<hr />
<div>This page describes the development model used by the web development team at WormBase using git as our version control system. This includes our branching strategy and release management. We use git and GitHub to help us manage development.<br />
<br />
= Overview Diagram =<br />
[[File:Git_Workflow_-_WormBase4.png]]<br />
<br />
[https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing Editable version of the diagram]<br />
<br />
= Contributing =<br />
<br />
Whenever you begin work on a new issue you should create a new branch for it. Any new major features should branch off <code>staging</code>. Once the feature is ready for testing, it can be merged back into <code>staging</code>. These aren't necessarily branches in the main repository - they can be local, or on a developer's fork. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Branch_stratgey Read more on our branching strategy]<br />
<br />
git checkout -b myFeature staging<br />
<br />
Now you can make your changes and commit some code. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Commit_messages Read more on commit messages]<br />
git add /PATH/TO/UPDATED/FILE<br />
git commit -m "Descriptive commit message"<br />
<br />
When you're ready, you can push your branch to GitHub<br />
<br />
git push origin myFeature<br />
<br />
Continue making changes until your code is ready for a code review. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Is_my_code_ready_for_review.3F Is my code ready for review?]<br />
<br />
When your code is ready, go to GitHub and create a Pull Request. [http://nathanhoad.net/git-workflow-forks-remotes-and-pull-requests More info on Pull Requests.]<br />
<br />
# Go to the repository where you pushed your changes<br />
# Switch to your branch (myFeature)<br />
# Click the green '''Compare & review''' button<br />
# After reviewing all the changes, click on '''Create pull request''' in the header to send the pull request<br />
# In the description, write a short summary of the issues and changes made along with some links for testing [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#What_info_should_I_include_in_a_Pull_Request.3F What info should I include in a Pull Request?]<br />
<br />
Wait for another member of the web development team to review and merge your pull request. If more changes are requested, you can push more commits to the same branch and it will be added to the pull request.<br />
<br />
Once your pull request is merged, locally bring in the changes and delete your issue branch<br />
git checkout staging<br />
git pull<br />
git branch -d myFeature<br />
<br />
Go to the original github issue:<br />
# Add the '''Under testing''' label to your issue<br />
# Comment on the issue to notify all involved that it is ready for testing. Add links for testing for the ease of testers.<br />
# Another member of the WormBase group will close the issue once they have tested it<br />
<br />
== Is my code ready for review? == <br />
<br />
Before you send a Pull Request, please make sure you have completed the following:<br />
<br />
* Written tests (API tests or REST tests) demonstrating the problem in the issue. [http://wiki.wormbase.org/index.php/Unit_Testing More info on testing]<br />
* Fix the problem (ie pass the tests)<br />
* Complete the issue as much as possible without curators seeing an example<br />
* Code style meeting the [http://wiki.wormbase.org/index.php/Coding_standards WormBase coding standards] (indentation, comments, no debug statements)<br />
<br />
== What info should I include in a Pull Request? ==<br />
<br />
To help your reviewer understand your code, please try to include the following in the Pull Request description<br />
<br />
* A link to the issue being addressed<br />
* Short summary of the problem<br />
* Some links to use for testing<br />
* Any other information that may be needed to testing (ie wormbase_local.conf changes, extra files needed, etc)<br />
<br />
== Commit messages ==<br />
git commit -m "COMMIT MESSAGE GOES HERE"<br />
<br />
Keep your commit message as descriptive as possible, reference any issues affected, close any this resolves:<br />
This is a summary of my commit.<br />
* here is a breakdown of the different changes<br />
* mention github users (@tharris) when appropriate<br />
* related to #YYY<br />
* fix #XXX<br />
<br />
Here is a template originally written by Tim Pope at tpope.net:<br />
<pre><br />
Short (50 chars or less) summary of changes<br />
<br />
More detailed explanatory text, if necessary. Wrap it to about 72<br />
characters or so. In some contexts, the first line is treated as the<br />
subject of an email and the rest of the text as the body. The blank<br />
line separating the summary from the body is critical (unless you omit<br />
the body entirely); tools like rebase can get confused if you run the<br />
two together.<br />
<br />
Further paragraphs come after blank lines.<br />
<br />
- Bullet points are okay, too<br />
<br />
- Typically a hyphen or asterisk is used for the bullet, preceded by a<br />
single space, with blank lines in between, but conventions vary here<br />
</pre><br />
<br />
= Code Review =<br />
<br />
All changes must go through a code review before being merged to the staging branch. At WormBase, this is done using Pull Requests. All members of the core development team are expected to keep an eye on the open Pull Requests and reviewing the ones they are most familiar with. Pull requests waiting for review should be left untouched for longer than two days after being assigned. <br />
<br />
* Test out the pull request (check out the branch)<br />
* Take a quick look at the code (are there comments? anything obvious missing)<br />
* Leave a comment on the PR if you notice anything that needs to be fixed<br />
* Merge the PR if you think it looks good<br />
<br />
= Testing =<br />
All issues need to be tested and closed by at least one person who is not the developer who made the change. Ideally, it would be the curator asking for the feature/fix.<br />
<br />
'''If you would like to help test''':<br />
* Look at the [https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']. <br />
* All the changes for these issues are available for testing on [http://staging.wormbase.org staging.wormbase.org].<br />
* You can test out the changes and leave any feedback you have in the issue comments. <br />
* If you think this feature/fix is ready for production, you can '''close the issue'''.<br />
<br />
= Branch Strategy =<br />
We use branches to help with our release management, testing strategy, and helping with parallel development among the team.<br />
<br />
== Main branches ==<br />
Inside the <code>WormBase/website</code> repository, there are three main branches: <code>master</code>, <code>staging</code> and <code>production</code>.<br />
<br />
* <code>master</code>: current, stable code. All new changes brought into master have been tested on [http://staging.wormbase.org staging.wormbase.org] and approved by either the curator requesting the change, or the development lead.<br />
<br />
* <code>staging</code>: any features/changes ready for testing should be pushed to the <code>staging</code> branch. This code gets pushed nightly to [http://staging.wormbase.org staging.wormbase.org].<br />
<br />
* <code>production</code>: the code currently in production. Branched off of <code>master</code> at each release.<br />
<br />
== Feature branches ==<br />
Any new major features should branch off <code>staging</code>. Once the feature is ready for testing, it can be merged back into <code>staging</code>. These aren't necessarily branches in the main repository - can be local, or on a developer's fork.<br />
<br />
<br />
== Hotfixes ==<br />
If a major bugfix is needed in production, create a hotfix branch from production. When finished, the branch needs to be merged back into <code>production</code> and <code>staging</code><br />
<br />
=== Begining a fix ===<br />
git checkout -b hotfix-issXXX production<br />
<br />
Fix the bug and commit the fix in one or more commits. Reference the github issue:<br />
git commit -m "Severe production bug<br />
* search redirecting to home page<br />
* fix #XXX"<br />
<br />
=== Closing the fix ===<br />
The fix needs to be merged back to both <code>production</code> and <code>staging</code><br />
git checkout staging<br />
git merge hotfix-issXXX<br />
<br />
git checkout production<br />
git merge hotfix-issXXX<br />
<br />
= Development Timeline =<br />
<br />
See: [https://docs.google.com/document/d/1zIOm95tV9A14n9xnkPkMgiOTGcOIzx161y9UbDZvfW4/pub WormBase Release Workflow]<br />
<br />
= Release Management =<br />
When production is ready to updated for release WSXXX:<br />
<br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:master...staging pull request from staging to master]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:production...master pull request from master to production]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Tag production branch with appropriate release name.<br />
<br />
<br />
git checkout production<br />
git tag -a WSXXX<br />
<br />
= Links =<br />
* [http://staging.wormbase.org staging site for testing]<br />
* [https://github.com/WormBase/website github repository]<br />
* [https://github.com/WormBase/website/issues github issue tracker]<br />
* [https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing workflow diagram]<br />
<br />
[[Category:Development General (Web Dev)]]<br />
[[Category:Getting Started (Web Dev)]]</div>Acabunochttps://wiki.wormbase.org/index.php?title=Development_workflow_-_webdev&diff=24296Development workflow - webdev2014-07-29T18:56:56Z<p>Acabunoc: /* Supporting branches */</p>
<hr />
<div>This page describes the development model used by the web development team at WormBase using git as our version control system. This includes our branching strategy and release management. We use git and GitHub to help us manage development.<br />
<br />
= Overview Diagram =<br />
[[File:Git_Workflow_-_WormBase4.png]]<br />
<br />
[https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing Editable version of the diagram]<br />
<br />
= Contributing =<br />
<br />
Whenever you begin work on a new issue you should create a new branch for it. Any new major features should branch off <code>staging</code>. Once the feature is ready for testing, it can be merged back into <code>staging</code>. These aren't necessarily branches in the main repository - they can be local, or on a developer's fork. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Branch_stratgey Read more on our branching strategy]<br />
<br />
git checkout -b myFeature staging<br />
<br />
Now you can make your changes and commit some code. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Commit_messages Read more on commit messages]<br />
git add /PATH/TO/UPDATED/FILE<br />
git commit -m "Descriptive commit message"<br />
<br />
When you're ready, you can push your branch to GitHub<br />
<br />
git push origin myFeature<br />
<br />
Continue making changes until your code is ready for a code review. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Is_my_code_ready_for_review.3F Is my code ready for review?]<br />
<br />
When your code is ready, go to GitHub and create a Pull Request. [http://nathanhoad.net/git-workflow-forks-remotes-and-pull-requests More info on Pull Requests.]<br />
<br />
# Go to the repository where you pushed your changes<br />
# Switch to your branch (myFeature)<br />
# Click the green '''Compare & review''' button<br />
# After reviewing all the changes, click on '''Create pull request''' in the header to send the pull request<br />
# In the description, write a short summary of the issues and changes made along with some links for testing [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#What_info_should_I_include_in_a_Pull_Request.3F What info should I include in a Pull Request?]<br />
<br />
Wait for another member of the web development team to review and merge your pull request. If more changes are requested, you can push more commits to the same branch and it will be added to the pull request.<br />
<br />
Once your pull request is merged, locally bring in the changes and delete your issue branch<br />
git checkout staging<br />
git pull<br />
git branch -d myFeature<br />
<br />
Go to the original github issue:<br />
# Add the '''Under testing''' label to your issue<br />
# Comment on the issue to notify all involved that it is ready for testing. Add links for testing for the ease of testers.<br />
# Another member of the WormBase group will close the issue once they have tested it<br />
<br />
== Is my code ready for review? == <br />
<br />
Before you send a Pull Request, please make sure you have completed the following:<br />
<br />
* Written tests (API tests or REST tests) demonstrating the problem in the issue. [http://wiki.wormbase.org/index.php/Unit_Testing More info on testing]<br />
* Fix the problem (ie pass the tests)<br />
* Complete the issue as much as possible without curators seeing an example<br />
* Code style meeting the [http://wiki.wormbase.org/index.php/Coding_standards WormBase coding standards] (indentation, comments, no debug statements)<br />
<br />
== What info should I include in a Pull Request? ==<br />
<br />
To help your reviewer understand your code, please try to include the following in the Pull Request description<br />
<br />
* A link to the issue being addressed<br />
* Short summary of the problem<br />
* Some links to use for testing<br />
* Any other information that may be needed to testing (ie wormbase_local.conf changes, extra files needed, etc)<br />
<br />
== Commit messages ==<br />
git commit -m "COMMIT MESSAGE GOES HERE"<br />
<br />
Keep your commit message as descriptive as possible, reference any issues affected, close any this resolves:<br />
This is a summary of my commit.<br />
* here is a breakdown of the different changes<br />
* mention github users (@tharris) when appropriate<br />
* related to #YYY<br />
* fix #XXX<br />
<br />
Here is a template originally written by Tim Pope at tpope.net:<br />
<pre><br />
Short (50 chars or less) summary of changes<br />
<br />
More detailed explanatory text, if necessary. Wrap it to about 72<br />
characters or so. In some contexts, the first line is treated as the<br />
subject of an email and the rest of the text as the body. The blank<br />
line separating the summary from the body is critical (unless you omit<br />
the body entirely); tools like rebase can get confused if you run the<br />
two together.<br />
<br />
Further paragraphs come after blank lines.<br />
<br />
- Bullet points are okay, too<br />
<br />
- Typically a hyphen or asterisk is used for the bullet, preceded by a<br />
single space, with blank lines in between, but conventions vary here<br />
</pre><br />
<br />
= Code Review =<br />
<br />
All changes must go through a code review before being merged to the staging branch. At WormBase, this is done using Pull Requests. All members of the core development team are expected to keep an eye on the open Pull Requests and reviewing the ones they are most familiar with. Pull requests waiting for review should be left untouched for longer than two days after being assigned. <br />
<br />
* Test out the pull request (check out the branch)<br />
* Take a quick look at the code (are there comments? anything obvious missing)<br />
* Leave a comment on the PR if you notice anything that needs to be fixed<br />
* Merge the PR if you think it looks good<br />
<br />
= Testing =<br />
All issues need to be tested and closed by at least one person who is not the developer who made the change. Ideally, it would be the curator asking for the feature/fix.<br />
<br />
'''If you would like to help test''':<br />
* Look at the [https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']. <br />
* All the changes for these issues are available for testing on [http://staging.wormbase.org staging.wormbase.org].<br />
* You can test out the changes and leave any feedback you have in the issue comments. <br />
* If you think this feature/fix is ready for production, you can '''remove the 'under testing' label''', or '''close the issue'''.<br />
<br />
= Branch Strategy =<br />
We use branches to help with our release management, testing strategy, and helping with parallel development among the team.<br />
<br />
== Main branches ==<br />
Inside the <code>WormBase/website</code> repository, there are three main branches: <code>master</code>, <code>staging</code> and <code>production</code>.<br />
<br />
* <code>master</code>: current, stable code. All new changes brought into master have been tested on [http://staging.wormbase.org staging.wormbase.org] and approved by either the curator requesting the change, or the development lead.<br />
<br />
* <code>staging</code>: any features/changes ready for testing should be pushed to the <code>staging</code> branch. This code gets pushed nightly to [http://staging.wormbase.org staging.wormbase.org].<br />
<br />
* <code>production</code>: the code currently in production. Branched off of <code>master</code> at each release.<br />
<br />
== Feature branches ==<br />
Any new major features should branch off <code>staging</code>. Once the feature is ready for testing, it can be merged back into <code>staging</code>. These aren't necessarily branches in the main repository - can be local, or on a developer's fork.<br />
<br />
<br />
== Hotfixes ==<br />
If a major bugfix is needed in production, create a hotfix branch from production. When finished, the branch needs to be merged back into <code>production</code> and <code>staging</code><br />
<br />
=== Begining a fix ===<br />
git checkout -b hotfix-issXXX production<br />
<br />
Fix the bug and commit the fix in one or more commits. Reference the github issue:<br />
git commit -m "Severe production bug<br />
* search redirecting to home page<br />
* fix #XXX"<br />
<br />
=== Closing the fix ===<br />
The fix needs to be merged back to both <code>production</code> and <code>staging</code><br />
git checkout staging<br />
git merge hotfix-issXXX<br />
<br />
git checkout production<br />
git merge hotfix-issXXX<br />
<br />
= Development Timeline =<br />
<br />
See: [https://docs.google.com/document/d/1zIOm95tV9A14n9xnkPkMgiOTGcOIzx161y9UbDZvfW4/pub WormBase Release Workflow]<br />
<br />
= Release Management =<br />
When production is ready to updated for release WSXXX:<br />
<br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:master...staging pull request from staging to master]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:production...master pull request from master to production]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Tag production branch with appropriate release name.<br />
<br />
<br />
git checkout production<br />
git tag -a WSXXX<br />
<br />
= Links =<br />
* [http://staging.wormbase.org staging site for testing]<br />
* [https://github.com/WormBase/website github repository]<br />
* [https://github.com/WormBase/website/issues github issue tracker]<br />
* [https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing workflow diagram]<br />
<br />
[[Category:Development General (Web Dev)]]<br />
[[Category:Getting Started (Web Dev)]]</div>Acabunochttps://wiki.wormbase.org/index.php?title=Development_workflow_-_webdev&diff=24295Development workflow - webdev2014-07-29T18:55:46Z<p>Acabunoc: /* Testing issues */</p>
<hr />
<div>This page describes the development model used by the web development team at WormBase using git as our version control system. This includes our branching strategy and release management. We use git and GitHub to help us manage development.<br />
<br />
= Overview Diagram =<br />
[[File:Git_Workflow_-_WormBase4.png]]<br />
<br />
[https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing Editable version of the diagram]<br />
<br />
= Contributing =<br />
<br />
Whenever you begin work on a new issue you should create a new branch for it. Any new major features should branch off <code>staging</code>. Once the feature is ready for testing, it can be merged back into <code>staging</code>. These aren't necessarily branches in the main repository - they can be local, or on a developer's fork. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Branch_stratgey Read more on our branching strategy]<br />
<br />
git checkout -b myFeature staging<br />
<br />
Now you can make your changes and commit some code. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Commit_messages Read more on commit messages]<br />
git add /PATH/TO/UPDATED/FILE<br />
git commit -m "Descriptive commit message"<br />
<br />
When you're ready, you can push your branch to GitHub<br />
<br />
git push origin myFeature<br />
<br />
Continue making changes until your code is ready for a code review. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Is_my_code_ready_for_review.3F Is my code ready for review?]<br />
<br />
When your code is ready, go to GitHub and create a Pull Request. [http://nathanhoad.net/git-workflow-forks-remotes-and-pull-requests More info on Pull Requests.]<br />
<br />
# Go to the repository where you pushed your changes<br />
# Switch to your branch (myFeature)<br />
# Click the green '''Compare & review''' button<br />
# After reviewing all the changes, click on '''Create pull request''' in the header to send the pull request<br />
# In the description, write a short summary of the issues and changes made along with some links for testing [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#What_info_should_I_include_in_a_Pull_Request.3F What info should I include in a Pull Request?]<br />
<br />
Wait for another member of the web development team to review and merge your pull request. If more changes are requested, you can push more commits to the same branch and it will be added to the pull request.<br />
<br />
Once your pull request is merged, locally bring in the changes and delete your issue branch<br />
git checkout staging<br />
git pull<br />
git branch -d myFeature<br />
<br />
Go to the original github issue:<br />
# Add the '''Under testing''' label to your issue<br />
# Comment on the issue to notify all involved that it is ready for testing. Add links for testing for the ease of testers.<br />
# Another member of the WormBase group will close the issue once they have tested it<br />
<br />
== Is my code ready for review? == <br />
<br />
Before you send a Pull Request, please make sure you have completed the following:<br />
<br />
* Written tests (API tests or REST tests) demonstrating the problem in the issue. [http://wiki.wormbase.org/index.php/Unit_Testing More info on testing]<br />
* Fix the problem (ie pass the tests)<br />
* Complete the issue as much as possible without curators seeing an example<br />
* Code style meeting the [http://wiki.wormbase.org/index.php/Coding_standards WormBase coding standards] (indentation, comments, no debug statements)<br />
<br />
== What info should I include in a Pull Request? ==<br />
<br />
To help your reviewer understand your code, please try to include the following in the Pull Request description<br />
<br />
* A link to the issue being addressed<br />
* Short summary of the problem<br />
* Some links to use for testing<br />
* Any other information that may be needed to testing (ie wormbase_local.conf changes, extra files needed, etc)<br />
<br />
== Commit messages ==<br />
git commit -m "COMMIT MESSAGE GOES HERE"<br />
<br />
Keep your commit message as descriptive as possible, reference any issues affected, close any this resolves:<br />
This is a summary of my commit.<br />
* here is a breakdown of the different changes<br />
* mention github users (@tharris) when appropriate<br />
* related to #YYY<br />
* fix #XXX<br />
<br />
Here is a template originally written by Tim Pope at tpope.net:<br />
<pre><br />
Short (50 chars or less) summary of changes<br />
<br />
More detailed explanatory text, if necessary. Wrap it to about 72<br />
characters or so. In some contexts, the first line is treated as the<br />
subject of an email and the rest of the text as the body. The blank<br />
line separating the summary from the body is critical (unless you omit<br />
the body entirely); tools like rebase can get confused if you run the<br />
two together.<br />
<br />
Further paragraphs come after blank lines.<br />
<br />
- Bullet points are okay, too<br />
<br />
- Typically a hyphen or asterisk is used for the bullet, preceded by a<br />
single space, with blank lines in between, but conventions vary here<br />
</pre><br />
<br />
= Code Review =<br />
<br />
All changes must go through a code review before being merged to the staging branch. At WormBase, this is done using Pull Requests. All members of the core development team are expected to keep an eye on the open Pull Requests and reviewing the ones they are most familiar with. Pull requests waiting for review should be left untouched for longer than two days after being assigned. <br />
<br />
* Test out the pull request (check out the branch)<br />
* Take a quick look at the code (are there comments? anything obvious missing)<br />
* Leave a comment on the PR if you notice anything that needs to be fixed<br />
* Merge the PR if you think it looks good<br />
<br />
= Testing =<br />
All issues need to be tested and closed by at least one person who is not the developer who made the change. Ideally, it would be the curator asking for the feature/fix.<br />
<br />
'''If you would like to help test''':<br />
* Look at the [https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']. <br />
* All the changes for these issues are available for testing on [http://staging.wormbase.org staging.wormbase.org].<br />
* You can test out the changes and leave any feedback you have in the issue comments. <br />
* If you think this feature/fix is ready for production, you can '''remove the 'under testing' label''', or '''close the issue'''.<br />
<br />
= Branch Strategy =<br />
We use branches to help with our release management, testing strategy, and helping with parallel development among the team.<br />
<br />
== Main branches ==<br />
Inside the <code>WormBase/website</code> repository, there are three main branches: <code>master</code>, <code>staging</code> and <code>production</code>.<br />
<br />
* <code>master</code>: current, stable code. All new changes brought into master have been tested on [http://staging.wormbase.org staging.wormbase.org] and approved by either the curator requesting the change, or the development lead.<br />
<br />
* <code>staging</code>: any features/changes ready for testing should be pushed to the <code>staging</code> branch. This code gets pushed nightly to [http://staging.wormbase.org staging.wormbase.org].<br />
<br />
* <code>production</code>: the code currently in production. Branched off of <code>master</code> at each release.<br />
<br />
== Supporting branches == <br />
Other types of branches used can include feature branches and hotfixes. These branches are only intended to live until the new feature is merged into <code>staging</code> or the fix is completed.<br />
<br />
<br />
=== Feature branches ===<br />
Any new major features should branch off <code>staging</code>. Once the feature is ready for testing, it can be merged back into <code>staging</code>. These aren't necessarily branches in the main repository - can be local, or on a developer's fork.<br />
<br />
<br />
=== Hotfixes ===<br />
If a major bugfix is needed in production, create a hotfix branch from production. When finished, the branch needs to be merged back into <code>production</code> and <code>staging</code><br />
<br />
==== Begining a fix ====<br />
git checkout -b hotfix-issXXX production<br />
<br />
Fix the bug and commit the fix in one or more commits. Reference the github issue:<br />
git commit -m "Severe production bug<br />
* search redirecting to home page<br />
* fix #XXX"<br />
<br />
==== Closing the fix ====<br />
The fix needs to be merged back to both <code>production</code> and <code>staging</code><br />
git checkout staging<br />
git merge hotfix-issXXX<br />
<br />
git checkout production<br />
git merge hotfix-issXXX<br />
<br />
<br />
= Development Timeline =<br />
<br />
See: [https://docs.google.com/document/d/1zIOm95tV9A14n9xnkPkMgiOTGcOIzx161y9UbDZvfW4/pub WormBase Release Workflow]<br />
<br />
= Release Management =<br />
When production is ready to updated for release WSXXX:<br />
<br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:master...staging pull request from staging to master]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:production...master pull request from master to production]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Tag production branch with appropriate release name.<br />
<br />
<br />
git checkout production<br />
git tag -a WSXXX<br />
<br />
= Links =<br />
* [http://staging.wormbase.org staging site for testing]<br />
* [https://github.com/WormBase/website github repository]<br />
* [https://github.com/WormBase/website/issues github issue tracker]<br />
* [https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing workflow diagram]<br />
<br />
[[Category:Development General (Web Dev)]]<br />
[[Category:Getting Started (Web Dev)]]</div>Acabunochttps://wiki.wormbase.org/index.php?title=Development_workflow_-_webdev&diff=24294Development workflow - webdev2014-07-29T18:55:14Z<p>Acabunoc: /* Moving a feature to master (pass testing) */</p>
<hr />
<div>This page describes the development model used by the web development team at WormBase using git as our version control system. This includes our branching strategy and release management. We use git and GitHub to help us manage development.<br />
<br />
= Overview Diagram =<br />
[[File:Git_Workflow_-_WormBase4.png]]<br />
<br />
[https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing Editable version of the diagram]<br />
<br />
= Contributing =<br />
<br />
Whenever you begin work on a new issue you should create a new branch for it. Any new major features should branch off <code>staging</code>. Once the feature is ready for testing, it can be merged back into <code>staging</code>. These aren't necessarily branches in the main repository - they can be local, or on a developer's fork. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Branch_stratgey Read more on our branching strategy]<br />
<br />
git checkout -b myFeature staging<br />
<br />
Now you can make your changes and commit some code. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Commit_messages Read more on commit messages]<br />
git add /PATH/TO/UPDATED/FILE<br />
git commit -m "Descriptive commit message"<br />
<br />
When you're ready, you can push your branch to GitHub<br />
<br />
git push origin myFeature<br />
<br />
Continue making changes until your code is ready for a code review. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Is_my_code_ready_for_review.3F Is my code ready for review?]<br />
<br />
When your code is ready, go to GitHub and create a Pull Request. [http://nathanhoad.net/git-workflow-forks-remotes-and-pull-requests More info on Pull Requests.]<br />
<br />
# Go to the repository where you pushed your changes<br />
# Switch to your branch (myFeature)<br />
# Click the green '''Compare & review''' button<br />
# After reviewing all the changes, click on '''Create pull request''' in the header to send the pull request<br />
# In the description, write a short summary of the issues and changes made along with some links for testing [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#What_info_should_I_include_in_a_Pull_Request.3F What info should I include in a Pull Request?]<br />
<br />
Wait for another member of the web development team to review and merge your pull request. If more changes are requested, you can push more commits to the same branch and it will be added to the pull request.<br />
<br />
Once your pull request is merged, locally bring in the changes and delete your issue branch<br />
git checkout staging<br />
git pull<br />
git branch -d myFeature<br />
<br />
Go to the original github issue:<br />
# Add the '''Under testing''' label to your issue<br />
# Comment on the issue to notify all involved that it is ready for testing. Add links for testing for the ease of testers.<br />
# Another member of the WormBase group will close the issue once they have tested it<br />
<br />
== Is my code ready for review? == <br />
<br />
Before you send a Pull Request, please make sure you have completed the following:<br />
<br />
* Written tests (API tests or REST tests) demonstrating the problem in the issue. [http://wiki.wormbase.org/index.php/Unit_Testing More info on testing]<br />
* Fix the problem (ie pass the tests)<br />
* Complete the issue as much as possible without curators seeing an example<br />
* Code style meeting the [http://wiki.wormbase.org/index.php/Coding_standards WormBase coding standards] (indentation, comments, no debug statements)<br />
<br />
== What info should I include in a Pull Request? ==<br />
<br />
To help your reviewer understand your code, please try to include the following in the Pull Request description<br />
<br />
* A link to the issue being addressed<br />
* Short summary of the problem<br />
* Some links to use for testing<br />
* Any other information that may be needed to testing (ie wormbase_local.conf changes, extra files needed, etc)<br />
<br />
== Commit messages ==<br />
git commit -m "COMMIT MESSAGE GOES HERE"<br />
<br />
Keep your commit message as descriptive as possible, reference any issues affected, close any this resolves:<br />
This is a summary of my commit.<br />
* here is a breakdown of the different changes<br />
* mention github users (@tharris) when appropriate<br />
* related to #YYY<br />
* fix #XXX<br />
<br />
Here is a template originally written by Tim Pope at tpope.net:<br />
<pre><br />
Short (50 chars or less) summary of changes<br />
<br />
More detailed explanatory text, if necessary. Wrap it to about 72<br />
characters or so. In some contexts, the first line is treated as the<br />
subject of an email and the rest of the text as the body. The blank<br />
line separating the summary from the body is critical (unless you omit<br />
the body entirely); tools like rebase can get confused if you run the<br />
two together.<br />
<br />
Further paragraphs come after blank lines.<br />
<br />
- Bullet points are okay, too<br />
<br />
- Typically a hyphen or asterisk is used for the bullet, preceded by a<br />
single space, with blank lines in between, but conventions vary here<br />
</pre><br />
<br />
= Code Review =<br />
<br />
All changes must go through a code review before being merged to the staging branch. At WormBase, this is done using Pull Requests. All members of the core development team are expected to keep an eye on the open Pull Requests and reviewing the ones they are most familiar with. Pull requests waiting for review should be left untouched for longer than two days after being assigned. <br />
<br />
* Test out the pull request (check out the branch)<br />
* Take a quick look at the code (are there comments? anything obvious missing)<br />
* Leave a comment on the PR if you notice anything that needs to be fixed<br />
* Merge the PR if you think it looks good<br />
<br />
= Testing =<br />
All issues need to be tested and closed by at least one person who is not the developer who made the change. Ideally, it would be the curator asking for the feature/fix.<br />
<br />
'''If you would like to help test''':<br />
* Look at the [https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']. <br />
* All the changes for these issues are available for testing on [http://staging.wormbase.org staging.wormbase.org].<br />
* You can test out the changes and leave any feedback you have in the issue comments. <br />
* If you think this feature/fix is ready for production, you can '''remove the 'under testing' label''', or '''close the issue'''.<br />
<br />
= Branch Strategy =<br />
We use branches to help with our release management, testing strategy, and helping with parallel development among the team.<br />
<br />
== Main branches ==<br />
Inside the <code>WormBase/website</code> repository, there are three main branches: <code>master</code>, <code>staging</code> and <code>production</code>.<br />
<br />
* <code>master</code>: current, stable code. All new changes brought into master have been tested on [http://staging.wormbase.org staging.wormbase.org] and approved by either the curator requesting the change, or the development lead.<br />
<br />
* <code>staging</code>: any features/changes ready for testing should be pushed to the <code>staging</code> branch. This code gets pushed nightly to [http://staging.wormbase.org staging.wormbase.org].<br />
<br />
* <code>production</code>: the code currently in production. Branched off of <code>master</code> at each release.<br />
<br />
== Supporting branches == <br />
Other types of branches used can include feature branches and hotfixes. These branches are only intended to live until the new feature is merged into <code>staging</code> or the fix is completed.<br />
<br />
<br />
=== Feature branches ===<br />
Any new major features should branch off <code>staging</code>. Once the feature is ready for testing, it can be merged back into <code>staging</code>. These aren't necessarily branches in the main repository - can be local, or on a developer's fork.<br />
<br />
<br />
==== Testing issues ====<br />
All issues need to be tested and closed by at least one person who is not the developer who made the change. Ideally, it would be the curator asking for the feature/fix.<br />
<br />
'''If you would like to help test''':<br />
* Look at the [https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']. <br />
* All the changes for these issues are available for testing on [http://staging.wormbase.org staging.wormbase.org].<br />
<br />
'''If you are not the developer who pushed the code for this issue''':<br />
* You can test out the changes and leave any feedback you have in the issue comments. <br />
* If you think this feature/fix is ready for production, you can '''remove the 'under testing' label''', or '''close the issue'''.<br />
<br />
=== Hotfixes ===<br />
If a major bugfix is needed in production, create a hotfix branch from production. When finished, the branch needs to be merged back into <code>production</code> and <code>staging</code><br />
<br />
==== Begining a fix ====<br />
git checkout -b hotfix-issXXX production<br />
<br />
Fix the bug and commit the fix in one or more commits. Reference the github issue:<br />
git commit -m "Severe production bug<br />
* search redirecting to home page<br />
* fix #XXX"<br />
<br />
==== Closing the fix ====<br />
The fix needs to be merged back to both <code>production</code> and <code>staging</code><br />
git checkout staging<br />
git merge hotfix-issXXX<br />
<br />
git checkout production<br />
git merge hotfix-issXXX<br />
<br />
<br />
= Development Timeline =<br />
<br />
See: [https://docs.google.com/document/d/1zIOm95tV9A14n9xnkPkMgiOTGcOIzx161y9UbDZvfW4/pub WormBase Release Workflow]<br />
<br />
= Release Management =<br />
When production is ready to updated for release WSXXX:<br />
<br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:master...staging pull request from staging to master]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:production...master pull request from master to production]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Tag production branch with appropriate release name.<br />
<br />
<br />
git checkout production<br />
git tag -a WSXXX<br />
<br />
= Links =<br />
* [http://staging.wormbase.org staging site for testing]<br />
* [https://github.com/WormBase/website github repository]<br />
* [https://github.com/WormBase/website/issues github issue tracker]<br />
* [https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing workflow diagram]<br />
<br />
[[Category:Development General (Web Dev)]]<br />
[[Category:Getting Started (Web Dev)]]</div>Acabunochttps://wiki.wormbase.org/index.php?title=Development_workflow_-_webdev&diff=24293Development workflow - webdev2014-07-29T18:54:38Z<p>Acabunoc: /* Commit messages */</p>
<hr />
<div>This page describes the development model used by the web development team at WormBase using git as our version control system. This includes our branching strategy and release management. We use git and GitHub to help us manage development.<br />
<br />
= Overview Diagram =<br />
[[File:Git_Workflow_-_WormBase4.png]]<br />
<br />
[https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing Editable version of the diagram]<br />
<br />
= Contributing =<br />
<br />
Whenever you begin work on a new issue you should create a new branch for it. Any new major features should branch off <code>staging</code>. Once the feature is ready for testing, it can be merged back into <code>staging</code>. These aren't necessarily branches in the main repository - they can be local, or on a developer's fork. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Branch_stratgey Read more on our branching strategy]<br />
<br />
git checkout -b myFeature staging<br />
<br />
Now you can make your changes and commit some code. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Commit_messages Read more on commit messages]<br />
git add /PATH/TO/UPDATED/FILE<br />
git commit -m "Descriptive commit message"<br />
<br />
When you're ready, you can push your branch to GitHub<br />
<br />
git push origin myFeature<br />
<br />
Continue making changes until your code is ready for a code review. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Is_my_code_ready_for_review.3F Is my code ready for review?]<br />
<br />
When your code is ready, go to GitHub and create a Pull Request. [http://nathanhoad.net/git-workflow-forks-remotes-and-pull-requests More info on Pull Requests.]<br />
<br />
# Go to the repository where you pushed your changes<br />
# Switch to your branch (myFeature)<br />
# Click the green '''Compare & review''' button<br />
# After reviewing all the changes, click on '''Create pull request''' in the header to send the pull request<br />
# In the description, write a short summary of the issues and changes made along with some links for testing [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#What_info_should_I_include_in_a_Pull_Request.3F What info should I include in a Pull Request?]<br />
<br />
Wait for another member of the web development team to review and merge your pull request. If more changes are requested, you can push more commits to the same branch and it will be added to the pull request.<br />
<br />
Once your pull request is merged, locally bring in the changes and delete your issue branch<br />
git checkout staging<br />
git pull<br />
git branch -d myFeature<br />
<br />
Go to the original github issue:<br />
# Add the '''Under testing''' label to your issue<br />
# Comment on the issue to notify all involved that it is ready for testing. Add links for testing for the ease of testers.<br />
# Another member of the WormBase group will close the issue once they have tested it<br />
<br />
== Is my code ready for review? == <br />
<br />
Before you send a Pull Request, please make sure you have completed the following:<br />
<br />
* Written tests (API tests or REST tests) demonstrating the problem in the issue. [http://wiki.wormbase.org/index.php/Unit_Testing More info on testing]<br />
* Fix the problem (ie pass the tests)<br />
* Complete the issue as much as possible without curators seeing an example<br />
* Code style meeting the [http://wiki.wormbase.org/index.php/Coding_standards WormBase coding standards] (indentation, comments, no debug statements)<br />
<br />
== What info should I include in a Pull Request? ==<br />
<br />
To help your reviewer understand your code, please try to include the following in the Pull Request description<br />
<br />
* A link to the issue being addressed<br />
* Short summary of the problem<br />
* Some links to use for testing<br />
* Any other information that may be needed to testing (ie wormbase_local.conf changes, extra files needed, etc)<br />
<br />
== Commit messages ==<br />
git commit -m "COMMIT MESSAGE GOES HERE"<br />
<br />
Keep your commit message as descriptive as possible, reference any issues affected, close any this resolves:<br />
This is a summary of my commit.<br />
* here is a breakdown of the different changes<br />
* mention github users (@tharris) when appropriate<br />
* related to #YYY<br />
* fix #XXX<br />
<br />
Here is a template originally written by Tim Pope at tpope.net:<br />
<pre><br />
Short (50 chars or less) summary of changes<br />
<br />
More detailed explanatory text, if necessary. Wrap it to about 72<br />
characters or so. In some contexts, the first line is treated as the<br />
subject of an email and the rest of the text as the body. The blank<br />
line separating the summary from the body is critical (unless you omit<br />
the body entirely); tools like rebase can get confused if you run the<br />
two together.<br />
<br />
Further paragraphs come after blank lines.<br />
<br />
- Bullet points are okay, too<br />
<br />
- Typically a hyphen or asterisk is used for the bullet, preceded by a<br />
single space, with blank lines in between, but conventions vary here<br />
</pre><br />
<br />
= Code Review =<br />
<br />
All changes must go through a code review before being merged to the staging branch. At WormBase, this is done using Pull Requests. All members of the core development team are expected to keep an eye on the open Pull Requests and reviewing the ones they are most familiar with. Pull requests waiting for review should be left untouched for longer than two days after being assigned. <br />
<br />
* Test out the pull request (check out the branch)<br />
* Take a quick look at the code (are there comments? anything obvious missing)<br />
* Leave a comment on the PR if you notice anything that needs to be fixed<br />
* Merge the PR if you think it looks good<br />
<br />
= Testing =<br />
All issues need to be tested and closed by at least one person who is not the developer who made the change. Ideally, it would be the curator asking for the feature/fix.<br />
<br />
'''If you would like to help test''':<br />
* Look at the [https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']. <br />
* All the changes for these issues are available for testing on [http://staging.wormbase.org staging.wormbase.org].<br />
* You can test out the changes and leave any feedback you have in the issue comments. <br />
* If you think this feature/fix is ready for production, you can '''remove the 'under testing' label''', or '''close the issue'''.<br />
<br />
= Branch Strategy =<br />
We use branches to help with our release management, testing strategy, and helping with parallel development among the team.<br />
<br />
== Main branches ==<br />
Inside the <code>WormBase/website</code> repository, there are three main branches: <code>master</code>, <code>staging</code> and <code>production</code>.<br />
<br />
* <code>master</code>: current, stable code. All new changes brought into master have been tested on [http://staging.wormbase.org staging.wormbase.org] and approved by either the curator requesting the change, or the development lead.<br />
<br />
* <code>staging</code>: any features/changes ready for testing should be pushed to the <code>staging</code> branch. This code gets pushed nightly to [http://staging.wormbase.org staging.wormbase.org].<br />
<br />
* <code>production</code>: the code currently in production. Branched off of <code>master</code> at each release.<br />
<br />
== Supporting branches == <br />
Other types of branches used can include feature branches and hotfixes. These branches are only intended to live until the new feature is merged into <code>staging</code> or the fix is completed.<br />
<br />
<br />
=== Feature branches ===<br />
Any new major features should branch off <code>staging</code>. Once the feature is ready for testing, it can be merged back into <code>staging</code>. These aren't necessarily branches in the main repository - can be local, or on a developer's fork.<br />
<br />
<br />
==== Testing issues ====<br />
All issues need to be tested and closed by at least one person who is not the developer who made the change. Ideally, it would be the curator asking for the feature/fix.<br />
<br />
'''If you would like to help test''':<br />
* Look at the [https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']. <br />
* All the changes for these issues are available for testing on [http://staging.wormbase.org staging.wormbase.org].<br />
<br />
'''If you are not the developer who pushed the code for this issue''':<br />
* You can test out the changes and leave any feedback you have in the issue comments. <br />
* If you think this feature/fix is ready for production, you can '''remove the 'under testing' label''', or '''close the issue'''.<br />
<br />
==== Moving a feature to <code>master</code> (pass testing) ====<br />
First, check to see which issues are currently being tested:<br />
[https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']<br />
<br />
If this list is '''empty''', <code>staging</code> can be merged onto the <code>master</code>.<br />
<br />
In github, create a [https://github.com/WormBase/website/pull/new/staging pull request for staging]. Look at the '''Commits''' and '''Files changes'''. In the comment, summary all the features/issues introduced and make sure they are stable. Click on '''send pull request'''.<br />
<br />
Once the pull request is reviewed, it can be merged into the master branch.<br />
<br />
=== Hotfixes ===<br />
If a major bugfix is needed in production, create a hotfix branch from production. When finished, the branch needs to be merged back into <code>production</code> and <code>staging</code><br />
<br />
==== Begining a fix ====<br />
git checkout -b hotfix-issXXX production<br />
<br />
Fix the bug and commit the fix in one or more commits. Reference the github issue:<br />
git commit -m "Severe production bug<br />
* search redirecting to home page<br />
* fix #XXX"<br />
<br />
==== Closing the fix ====<br />
The fix needs to be merged back to both <code>production</code> and <code>staging</code><br />
git checkout staging<br />
git merge hotfix-issXXX<br />
<br />
git checkout production<br />
git merge hotfix-issXXX<br />
<br />
<br />
= Development Timeline =<br />
<br />
See: [https://docs.google.com/document/d/1zIOm95tV9A14n9xnkPkMgiOTGcOIzx161y9UbDZvfW4/pub WormBase Release Workflow]<br />
<br />
= Release Management =<br />
When production is ready to updated for release WSXXX:<br />
<br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:master...staging pull request from staging to master]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:production...master pull request from master to production]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Tag production branch with appropriate release name.<br />
<br />
<br />
git checkout production<br />
git tag -a WSXXX<br />
<br />
= Links =<br />
* [http://staging.wormbase.org staging site for testing]<br />
* [https://github.com/WormBase/website github repository]<br />
* [https://github.com/WormBase/website/issues github issue tracker]<br />
* [https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing workflow diagram]<br />
<br />
[[Category:Development General (Web Dev)]]<br />
[[Category:Getting Started (Web Dev)]]</div>Acabunochttps://wiki.wormbase.org/index.php?title=Development_workflow_-_webdev&diff=24292Development workflow - webdev2014-07-29T18:54:18Z<p>Acabunoc: /* Testing & Code Review */</p>
<hr />
<div>This page describes the development model used by the web development team at WormBase using git as our version control system. This includes our branching strategy and release management. We use git and GitHub to help us manage development.<br />
<br />
= Overview Diagram =<br />
[[File:Git_Workflow_-_WormBase4.png]]<br />
<br />
[https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing Editable version of the diagram]<br />
<br />
= Contributing =<br />
<br />
Whenever you begin work on a new issue you should create a new branch for it. Any new major features should branch off <code>staging</code>. Once the feature is ready for testing, it can be merged back into <code>staging</code>. These aren't necessarily branches in the main repository - they can be local, or on a developer's fork. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Branch_stratgey Read more on our branching strategy]<br />
<br />
git checkout -b myFeature staging<br />
<br />
Now you can make your changes and commit some code. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Commit_messages Read more on commit messages]<br />
git add /PATH/TO/UPDATED/FILE<br />
git commit -m "Descriptive commit message"<br />
<br />
When you're ready, you can push your branch to GitHub<br />
<br />
git push origin myFeature<br />
<br />
Continue making changes until your code is ready for a code review. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Is_my_code_ready_for_review.3F Is my code ready for review?]<br />
<br />
When your code is ready, go to GitHub and create a Pull Request. [http://nathanhoad.net/git-workflow-forks-remotes-and-pull-requests More info on Pull Requests.]<br />
<br />
# Go to the repository where you pushed your changes<br />
# Switch to your branch (myFeature)<br />
# Click the green '''Compare & review''' button<br />
# After reviewing all the changes, click on '''Create pull request''' in the header to send the pull request<br />
# In the description, write a short summary of the issues and changes made along with some links for testing [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#What_info_should_I_include_in_a_Pull_Request.3F What info should I include in a Pull Request?]<br />
<br />
Wait for another member of the web development team to review and merge your pull request. If more changes are requested, you can push more commits to the same branch and it will be added to the pull request.<br />
<br />
Once your pull request is merged, locally bring in the changes and delete your issue branch<br />
git checkout staging<br />
git pull<br />
git branch -d myFeature<br />
<br />
Go to the original github issue:<br />
# Add the '''Under testing''' label to your issue<br />
# Comment on the issue to notify all involved that it is ready for testing. Add links for testing for the ease of testers.<br />
# Another member of the WormBase group will close the issue once they have tested it<br />
<br />
== Is my code ready for review? == <br />
<br />
Before you send a Pull Request, please make sure you have completed the following:<br />
<br />
* Written tests (API tests or REST tests) demonstrating the problem in the issue. [http://wiki.wormbase.org/index.php/Unit_Testing More info on testing]<br />
* Fix the problem (ie pass the tests)<br />
* Complete the issue as much as possible without curators seeing an example<br />
* Code style meeting the [http://wiki.wormbase.org/index.php/Coding_standards WormBase coding standards] (indentation, comments, no debug statements)<br />
<br />
== What info should I include in a Pull Request? ==<br />
<br />
To help your reviewer understand your code, please try to include the following in the Pull Request description<br />
<br />
* A link to the issue being addressed<br />
* Short summary of the problem<br />
* Some links to use for testing<br />
* Any other information that may be needed to testing (ie wormbase_local.conf changes, extra files needed, etc)<br />
<br />
== Commit messages ==<br />
git commit -m "COMMIT MESSAGE GOES HERE"<br />
<br />
Keep your commit message as descriptive as possible, reference any issues affected, close any this resolves:<br />
This is a summary of my commit.<br />
* here is a breakdown of the different changes<br />
* mention github users (@tharris) when appropriate<br />
* related to #YYY<br />
* fix #XXX<br />
<br />
Here is a template originally written by Tim Pope at tpope.net:<br />
<pre><br />
Short (50 chars or less) summary of changes<br />
<br />
More detailed explanatory text, if necessary. Wrap it to about 72<br />
characters or so. In some contexts, the first line is treated as the<br />
subject of an email and the rest of the text as the body. The blank<br />
line separating the summary from the body is critical (unless you omit<br />
the body entirely); tools like rebase can get confused if you run the<br />
two together.<br />
<br />
Further paragraphs come after blank lines.<br />
<br />
- Bullet points are okay, too<br />
<br />
- Typically a hyphen or asterisk is used for the bullet, preceded by a<br />
single space, with blank lines in between, but conventions vary here<br />
</pre><br />
<br />
<br />
= Code Review =<br />
<br />
All changes must go through a code review before being merged to the staging branch. At WormBase, this is done using Pull Requests. All members of the core development team are expected to keep an eye on the open Pull Requests and reviewing the ones they are most familiar with. Pull requests waiting for review should be left untouched for longer than two days after being assigned. <br />
<br />
* Test out the pull request (check out the branch)<br />
* Take a quick look at the code (are there comments? anything obvious missing)<br />
* Leave a comment on the PR if you notice anything that needs to be fixed<br />
* Merge the PR if you think it looks good<br />
<br />
= Testing =<br />
All issues need to be tested and closed by at least one person who is not the developer who made the change. Ideally, it would be the curator asking for the feature/fix.<br />
<br />
'''If you would like to help test''':<br />
* Look at the [https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']. <br />
* All the changes for these issues are available for testing on [http://staging.wormbase.org staging.wormbase.org].<br />
* You can test out the changes and leave any feedback you have in the issue comments. <br />
* If you think this feature/fix is ready for production, you can '''remove the 'under testing' label''', or '''close the issue'''.<br />
<br />
= Branch Strategy =<br />
We use branches to help with our release management, testing strategy, and helping with parallel development among the team.<br />
<br />
== Main branches ==<br />
Inside the <code>WormBase/website</code> repository, there are three main branches: <code>master</code>, <code>staging</code> and <code>production</code>.<br />
<br />
* <code>master</code>: current, stable code. All new changes brought into master have been tested on [http://staging.wormbase.org staging.wormbase.org] and approved by either the curator requesting the change, or the development lead.<br />
<br />
* <code>staging</code>: any features/changes ready for testing should be pushed to the <code>staging</code> branch. This code gets pushed nightly to [http://staging.wormbase.org staging.wormbase.org].<br />
<br />
* <code>production</code>: the code currently in production. Branched off of <code>master</code> at each release.<br />
<br />
== Supporting branches == <br />
Other types of branches used can include feature branches and hotfixes. These branches are only intended to live until the new feature is merged into <code>staging</code> or the fix is completed.<br />
<br />
<br />
=== Feature branches ===<br />
Any new major features should branch off <code>staging</code>. Once the feature is ready for testing, it can be merged back into <code>staging</code>. These aren't necessarily branches in the main repository - can be local, or on a developer's fork.<br />
<br />
<br />
==== Testing issues ====<br />
All issues need to be tested and closed by at least one person who is not the developer who made the change. Ideally, it would be the curator asking for the feature/fix.<br />
<br />
'''If you would like to help test''':<br />
* Look at the [https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']. <br />
* All the changes for these issues are available for testing on [http://staging.wormbase.org staging.wormbase.org].<br />
<br />
'''If you are not the developer who pushed the code for this issue''':<br />
* You can test out the changes and leave any feedback you have in the issue comments. <br />
* If you think this feature/fix is ready for production, you can '''remove the 'under testing' label''', or '''close the issue'''.<br />
<br />
==== Moving a feature to <code>master</code> (pass testing) ====<br />
First, check to see which issues are currently being tested:<br />
[https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']<br />
<br />
If this list is '''empty''', <code>staging</code> can be merged onto the <code>master</code>.<br />
<br />
In github, create a [https://github.com/WormBase/website/pull/new/staging pull request for staging]. Look at the '''Commits''' and '''Files changes'''. In the comment, summary all the features/issues introduced and make sure they are stable. Click on '''send pull request'''.<br />
<br />
Once the pull request is reviewed, it can be merged into the master branch.<br />
<br />
=== Hotfixes ===<br />
If a major bugfix is needed in production, create a hotfix branch from production. When finished, the branch needs to be merged back into <code>production</code> and <code>staging</code><br />
<br />
==== Begining a fix ====<br />
git checkout -b hotfix-issXXX production<br />
<br />
Fix the bug and commit the fix in one or more commits. Reference the github issue:<br />
git commit -m "Severe production bug<br />
* search redirecting to home page<br />
* fix #XXX"<br />
<br />
==== Closing the fix ====<br />
The fix needs to be merged back to both <code>production</code> and <code>staging</code><br />
git checkout staging<br />
git merge hotfix-issXXX<br />
<br />
git checkout production<br />
git merge hotfix-issXXX<br />
<br />
<br />
= Development Timeline =<br />
<br />
See: [https://docs.google.com/document/d/1zIOm95tV9A14n9xnkPkMgiOTGcOIzx161y9UbDZvfW4/pub WormBase Release Workflow]<br />
<br />
= Release Management =<br />
When production is ready to updated for release WSXXX:<br />
<br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:master...staging pull request from staging to master]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:production...master pull request from master to production]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Tag production branch with appropriate release name.<br />
<br />
<br />
git checkout production<br />
git tag -a WSXXX<br />
<br />
= Links =<br />
* [http://staging.wormbase.org staging site for testing]<br />
* [https://github.com/WormBase/website github repository]<br />
* [https://github.com/WormBase/website/issues github issue tracker]<br />
* [https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing workflow diagram]<br />
<br />
[[Category:Development General (Web Dev)]]<br />
[[Category:Getting Started (Web Dev)]]</div>Acabunochttps://wiki.wormbase.org/index.php?title=Development_workflow_-_webdev&diff=24291Development workflow - webdev2014-07-29T18:50:45Z<p>Acabunoc: /* Contributing */</p>
<hr />
<div>This page describes the development model used by the web development team at WormBase using git as our version control system. This includes our branching strategy and release management. We use git and GitHub to help us manage development.<br />
<br />
= Overview Diagram =<br />
[[File:Git_Workflow_-_WormBase4.png]]<br />
<br />
[https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing Editable version of the diagram]<br />
<br />
= Contributing =<br />
<br />
Whenever you begin work on a new issue you should create a new branch for it. Any new major features should branch off <code>staging</code>. Once the feature is ready for testing, it can be merged back into <code>staging</code>. These aren't necessarily branches in the main repository - they can be local, or on a developer's fork. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Branch_stratgey Read more on our branching strategy]<br />
<br />
git checkout -b myFeature staging<br />
<br />
Now you can make your changes and commit some code. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Commit_messages Read more on commit messages]<br />
git add /PATH/TO/UPDATED/FILE<br />
git commit -m "Descriptive commit message"<br />
<br />
When you're ready, you can push your branch to GitHub<br />
<br />
git push origin myFeature<br />
<br />
Continue making changes until your code is ready for a code review. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Is_my_code_ready_for_review.3F Is my code ready for review?]<br />
<br />
When your code is ready, go to GitHub and create a Pull Request. [http://nathanhoad.net/git-workflow-forks-remotes-and-pull-requests More info on Pull Requests.]<br />
<br />
# Go to the repository where you pushed your changes<br />
# Switch to your branch (myFeature)<br />
# Click the green '''Compare & review''' button<br />
# After reviewing all the changes, click on '''Create pull request''' in the header to send the pull request<br />
# In the description, write a short summary of the issues and changes made along with some links for testing [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#What_info_should_I_include_in_a_Pull_Request.3F What info should I include in a Pull Request?]<br />
<br />
Wait for another member of the web development team to review and merge your pull request. If more changes are requested, you can push more commits to the same branch and it will be added to the pull request.<br />
<br />
Once your pull request is merged, locally bring in the changes and delete your issue branch<br />
git checkout staging<br />
git pull<br />
git branch -d myFeature<br />
<br />
Go to the original github issue:<br />
# Add the '''Under testing''' label to your issue<br />
# Comment on the issue to notify all involved that it is ready for testing. Add links for testing for the ease of testers.<br />
# Another member of the WormBase group will close the issue once they have tested it<br />
<br />
== Is my code ready for review? == <br />
<br />
Before you send a Pull Request, please make sure you have completed the following:<br />
<br />
* Written tests (API tests or REST tests) demonstrating the problem in the issue. [http://wiki.wormbase.org/index.php/Unit_Testing More info on testing]<br />
* Fix the problem (ie pass the tests)<br />
* Complete the issue as much as possible without curators seeing an example<br />
* Code style meeting the [http://wiki.wormbase.org/index.php/Coding_standards WormBase coding standards] (indentation, comments, no debug statements)<br />
<br />
== What info should I include in a Pull Request? ==<br />
<br />
To help your reviewer understand your code, please try to include the following in the Pull Request description<br />
<br />
* A link to the issue being addressed<br />
* Short summary of the problem<br />
* Some links to use for testing<br />
* Any other information that may be needed to testing (ie wormbase_local.conf changes, extra files needed, etc)<br />
<br />
== Commit messages ==<br />
git commit -m "COMMIT MESSAGE GOES HERE"<br />
<br />
Keep your commit message as descriptive as possible, reference any issues affected, close any this resolves:<br />
This is a summary of my commit.<br />
* here is a breakdown of the different changes<br />
* mention github users (@tharris) when appropriate<br />
* related to #YYY<br />
* fix #XXX<br />
<br />
Here is a template originally written by Tim Pope at tpope.net:<br />
<pre><br />
Short (50 chars or less) summary of changes<br />
<br />
More detailed explanatory text, if necessary. Wrap it to about 72<br />
characters or so. In some contexts, the first line is treated as the<br />
subject of an email and the rest of the text as the body. The blank<br />
line separating the summary from the body is critical (unless you omit<br />
the body entirely); tools like rebase can get confused if you run the<br />
two together.<br />
<br />
Further paragraphs come after blank lines.<br />
<br />
- Bullet points are okay, too<br />
<br />
- Typically a hyphen or asterisk is used for the bullet, preceded by a<br />
single space, with blank lines in between, but conventions vary here<br />
</pre><br />
<br />
= Testing & Code Review =<br />
There are two levels of review in our workflow.<br />
<br />
# Code review: At the pull request level, before code goes live on staging.wormbase.org<br />
# At the issue level, before closing an issue<br />
<br />
== Code Review: Pull Requests ==<br />
This level of testing is typically a code review before a Pull Request is merged into the staging branch. All members of the core development team are expected to keep an eye on the open Pull Requests and reviewing the ones they are most familiar with. Pull requests waiting for review should be left untouched for longer than two days after being assigned. <br />
<br />
* Test out the pull request (check out the branch)<br />
* Take a quick look at the code (are there comments? anything obvious missing)<br />
* Leave a comment on the PR if you notice anything that needs to be fixed<br />
* Merge the PR if you think it looks good<br />
<br />
== Testing: Issues ==<br />
All issues need to be tested and closed by at least one person who is not the developer who made the change. Ideally, it would be the curator asking for the feature/fix.<br />
<br />
'''If you would like to help test''':<br />
* Look at the [https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']. <br />
* All the changes for these issues are available for testing on [http://staging.wormbase.org staging.wormbase.org].<br />
* You can test out the changes and leave any feedback you have in the issue comments. <br />
* If you think this feature/fix is ready for production, you can '''remove the 'under testing' label''', or '''close the issue'''.<br />
<br />
= Branch Strategy =<br />
We use branches to help with our release management, testing strategy, and helping with parallel development among the team.<br />
<br />
== Main branches ==<br />
Inside the <code>WormBase/website</code> repository, there are three main branches: <code>master</code>, <code>staging</code> and <code>production</code>.<br />
<br />
* <code>master</code>: current, stable code. All new changes brought into master have been tested on [http://staging.wormbase.org staging.wormbase.org] and approved by either the curator requesting the change, or the development lead.<br />
<br />
* <code>staging</code>: any features/changes ready for testing should be pushed to the <code>staging</code> branch. This code gets pushed nightly to [http://staging.wormbase.org staging.wormbase.org].<br />
<br />
* <code>production</code>: the code currently in production. Branched off of <code>master</code> at each release.<br />
<br />
== Supporting branches == <br />
Other types of branches used can include feature branches and hotfixes. These branches are only intended to live until the new feature is merged into <code>staging</code> or the fix is completed.<br />
<br />
<br />
=== Feature branches ===<br />
Any new major features should branch off <code>staging</code>. Once the feature is ready for testing, it can be merged back into <code>staging</code>. These aren't necessarily branches in the main repository - can be local, or on a developer's fork.<br />
<br />
<br />
==== Testing issues ====<br />
All issues need to be tested and closed by at least one person who is not the developer who made the change. Ideally, it would be the curator asking for the feature/fix.<br />
<br />
'''If you would like to help test''':<br />
* Look at the [https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']. <br />
* All the changes for these issues are available for testing on [http://staging.wormbase.org staging.wormbase.org].<br />
<br />
'''If you are not the developer who pushed the code for this issue''':<br />
* You can test out the changes and leave any feedback you have in the issue comments. <br />
* If you think this feature/fix is ready for production, you can '''remove the 'under testing' label''', or '''close the issue'''.<br />
<br />
==== Moving a feature to <code>master</code> (pass testing) ====<br />
First, check to see which issues are currently being tested:<br />
[https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']<br />
<br />
If this list is '''empty''', <code>staging</code> can be merged onto the <code>master</code>.<br />
<br />
In github, create a [https://github.com/WormBase/website/pull/new/staging pull request for staging]. Look at the '''Commits''' and '''Files changes'''. In the comment, summary all the features/issues introduced and make sure they are stable. Click on '''send pull request'''.<br />
<br />
Once the pull request is reviewed, it can be merged into the master branch.<br />
<br />
=== Hotfixes ===<br />
If a major bugfix is needed in production, create a hotfix branch from production. When finished, the branch needs to be merged back into <code>production</code> and <code>staging</code><br />
<br />
==== Begining a fix ====<br />
git checkout -b hotfix-issXXX production<br />
<br />
Fix the bug and commit the fix in one or more commits. Reference the github issue:<br />
git commit -m "Severe production bug<br />
* search redirecting to home page<br />
* fix #XXX"<br />
<br />
==== Closing the fix ====<br />
The fix needs to be merged back to both <code>production</code> and <code>staging</code><br />
git checkout staging<br />
git merge hotfix-issXXX<br />
<br />
git checkout production<br />
git merge hotfix-issXXX<br />
<br />
<br />
= Development Timeline =<br />
<br />
See: [https://docs.google.com/document/d/1zIOm95tV9A14n9xnkPkMgiOTGcOIzx161y9UbDZvfW4/pub WormBase Release Workflow]<br />
<br />
= Release Management =<br />
When production is ready to updated for release WSXXX:<br />
<br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:master...staging pull request from staging to master]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:production...master pull request from master to production]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Tag production branch with appropriate release name.<br />
<br />
<br />
git checkout production<br />
git tag -a WSXXX<br />
<br />
= Links =<br />
* [http://staging.wormbase.org staging site for testing]<br />
* [https://github.com/WormBase/website github repository]<br />
* [https://github.com/WormBase/website/issues github issue tracker]<br />
* [https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing workflow diagram]<br />
<br />
[[Category:Development General (Web Dev)]]<br />
[[Category:Getting Started (Web Dev)]]</div>Acabunochttps://wiki.wormbase.org/index.php?title=Development_workflow_-_webdev&diff=24290Development workflow - webdev2014-07-29T18:50:24Z<p>Acabunoc: /* Commit Messages */</p>
<hr />
<div>This page describes the development model used by the web development team at WormBase using git as our version control system. This includes our branching strategy and release management. We use git and GitHub to help us manage development.<br />
<br />
= Overview Diagram =<br />
[[File:Git_Workflow_-_WormBase4.png]]<br />
<br />
[https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing Editable version of the diagram]<br />
<br />
= Contributing =<br />
<br />
Whenever you begin work on a new issue you should create a new branch for it. Any new major features should branch off <code>staging</code>. Once the feature is ready for testing, it can be merged back into <code>staging</code>. These aren't necessarily branches in the main repository - they can be local, or on a developer's fork. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Branch_stratgey Read more on our branching strategy]<br />
<br />
git checkout -b myFeature staging<br />
<br />
Now you can make your changes and commit some code. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Commit_Messages Read more on commit messages]<br />
git add /PATH/TO/UPDATED/FILE<br />
git commit -m "Descriptive commit message"<br />
<br />
When you're ready, you can push your branch to GitHub<br />
<br />
git push origin myFeature<br />
<br />
Continue making changes until your code is ready for a code review. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Is_my_code_ready_for_review.3F Is my code ready for review?]<br />
<br />
When your code is ready, go to GitHub and create a Pull Request. [http://nathanhoad.net/git-workflow-forks-remotes-and-pull-requests More info on Pull Requests.]<br />
<br />
# Go to the repository where you pushed your changes<br />
# Switch to your branch (myFeature)<br />
# Click the green '''Compare & review''' button<br />
# After reviewing all the changes, click on '''Create pull request''' in the header to send the pull request<br />
# In the description, write a short summary of the issues and changes made along with some links for testing [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#What_info_should_I_include_in_a_Pull_Request.3F What info should I include in a Pull Request?]<br />
<br />
Wait for another member of the web development team to review and merge your pull request. If more changes are requested, you can push more commits to the same branch and it will be added to the pull request.<br />
<br />
Once your pull request is merged, locally bring in the changes and delete your issue branch<br />
git checkout staging<br />
git pull<br />
git branch -d myFeature<br />
<br />
Go to the original github issue:<br />
# Add the '''Under testing''' label to your issue<br />
# Comment on the issue to notify all involved that it is ready for testing. Add links for testing for the ease of testers.<br />
# Another member of the WormBase group will close the issue once they have tested it<br />
<br />
== Is my code ready for review? == <br />
<br />
Before you send a Pull Request, please make sure you have completed the following:<br />
<br />
* Written tests (API tests or REST tests) demonstrating the problem in the issue. [http://wiki.wormbase.org/index.php/Unit_Testing More info on testing]<br />
* Fix the problem (ie pass the tests)<br />
* Complete the issue as much as possible without curators seeing an example<br />
* Code style meeting the [http://wiki.wormbase.org/index.php/Coding_standards WormBase coding standards] (indentation, comments, no debug statements)<br />
<br />
== What info should I include in a Pull Request? ==<br />
<br />
To help your reviewer understand your code, please try to include the following in the Pull Request description<br />
<br />
* A link to the issue being addressed<br />
* Short summary of the problem<br />
* Some links to use for testing<br />
* Any other information that may be needed to testing (ie wormbase_local.conf changes, extra files needed, etc)<br />
<br />
== Commit messages ==<br />
git commit -m "COMMIT MESSAGE GOES HERE"<br />
<br />
Keep your commit message as descriptive as possible, reference any issues affected, close any this resolves:<br />
This is a summary of my commit.<br />
* here is a breakdown of the different changes<br />
* mention github users (@tharris) when appropriate<br />
* related to #YYY<br />
* fix #XXX<br />
<br />
Here is a template originally written by Tim Pope at tpope.net:<br />
<pre><br />
Short (50 chars or less) summary of changes<br />
<br />
More detailed explanatory text, if necessary. Wrap it to about 72<br />
characters or so. In some contexts, the first line is treated as the<br />
subject of an email and the rest of the text as the body. The blank<br />
line separating the summary from the body is critical (unless you omit<br />
the body entirely); tools like rebase can get confused if you run the<br />
two together.<br />
<br />
Further paragraphs come after blank lines.<br />
<br />
- Bullet points are okay, too<br />
<br />
- Typically a hyphen or asterisk is used for the bullet, preceded by a<br />
single space, with blank lines in between, but conventions vary here<br />
</pre><br />
<br />
= Testing & Code Review =<br />
There are two levels of review in our workflow.<br />
<br />
# Code review: At the pull request level, before code goes live on staging.wormbase.org<br />
# At the issue level, before closing an issue<br />
<br />
== Code Review: Pull Requests ==<br />
This level of testing is typically a code review before a Pull Request is merged into the staging branch. All members of the core development team are expected to keep an eye on the open Pull Requests and reviewing the ones they are most familiar with. Pull requests waiting for review should be left untouched for longer than two days after being assigned. <br />
<br />
* Test out the pull request (check out the branch)<br />
* Take a quick look at the code (are there comments? anything obvious missing)<br />
* Leave a comment on the PR if you notice anything that needs to be fixed<br />
* Merge the PR if you think it looks good<br />
<br />
== Testing: Issues ==<br />
All issues need to be tested and closed by at least one person who is not the developer who made the change. Ideally, it would be the curator asking for the feature/fix.<br />
<br />
'''If you would like to help test''':<br />
* Look at the [https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']. <br />
* All the changes for these issues are available for testing on [http://staging.wormbase.org staging.wormbase.org].<br />
* You can test out the changes and leave any feedback you have in the issue comments. <br />
* If you think this feature/fix is ready for production, you can '''remove the 'under testing' label''', or '''close the issue'''.<br />
<br />
= Branch Strategy =<br />
We use branches to help with our release management, testing strategy, and helping with parallel development among the team.<br />
<br />
== Main branches ==<br />
Inside the <code>WormBase/website</code> repository, there are three main branches: <code>master</code>, <code>staging</code> and <code>production</code>.<br />
<br />
* <code>master</code>: current, stable code. All new changes brought into master have been tested on [http://staging.wormbase.org staging.wormbase.org] and approved by either the curator requesting the change, or the development lead.<br />
<br />
* <code>staging</code>: any features/changes ready for testing should be pushed to the <code>staging</code> branch. This code gets pushed nightly to [http://staging.wormbase.org staging.wormbase.org].<br />
<br />
* <code>production</code>: the code currently in production. Branched off of <code>master</code> at each release.<br />
<br />
== Supporting branches == <br />
Other types of branches used can include feature branches and hotfixes. These branches are only intended to live until the new feature is merged into <code>staging</code> or the fix is completed.<br />
<br />
<br />
=== Feature branches ===<br />
Any new major features should branch off <code>staging</code>. Once the feature is ready for testing, it can be merged back into <code>staging</code>. These aren't necessarily branches in the main repository - can be local, or on a developer's fork.<br />
<br />
<br />
==== Testing issues ====<br />
All issues need to be tested and closed by at least one person who is not the developer who made the change. Ideally, it would be the curator asking for the feature/fix.<br />
<br />
'''If you would like to help test''':<br />
* Look at the [https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']. <br />
* All the changes for these issues are available for testing on [http://staging.wormbase.org staging.wormbase.org].<br />
<br />
'''If you are not the developer who pushed the code for this issue''':<br />
* You can test out the changes and leave any feedback you have in the issue comments. <br />
* If you think this feature/fix is ready for production, you can '''remove the 'under testing' label''', or '''close the issue'''.<br />
<br />
==== Moving a feature to <code>master</code> (pass testing) ====<br />
First, check to see which issues are currently being tested:<br />
[https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']<br />
<br />
If this list is '''empty''', <code>staging</code> can be merged onto the <code>master</code>.<br />
<br />
In github, create a [https://github.com/WormBase/website/pull/new/staging pull request for staging]. Look at the '''Commits''' and '''Files changes'''. In the comment, summary all the features/issues introduced and make sure they are stable. Click on '''send pull request'''.<br />
<br />
Once the pull request is reviewed, it can be merged into the master branch.<br />
<br />
=== Hotfixes ===<br />
If a major bugfix is needed in production, create a hotfix branch from production. When finished, the branch needs to be merged back into <code>production</code> and <code>staging</code><br />
<br />
==== Begining a fix ====<br />
git checkout -b hotfix-issXXX production<br />
<br />
Fix the bug and commit the fix in one or more commits. Reference the github issue:<br />
git commit -m "Severe production bug<br />
* search redirecting to home page<br />
* fix #XXX"<br />
<br />
==== Closing the fix ====<br />
The fix needs to be merged back to both <code>production</code> and <code>staging</code><br />
git checkout staging<br />
git merge hotfix-issXXX<br />
<br />
git checkout production<br />
git merge hotfix-issXXX<br />
<br />
<br />
= Development Timeline =<br />
<br />
See: [https://docs.google.com/document/d/1zIOm95tV9A14n9xnkPkMgiOTGcOIzx161y9UbDZvfW4/pub WormBase Release Workflow]<br />
<br />
= Release Management =<br />
When production is ready to updated for release WSXXX:<br />
<br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:master...staging pull request from staging to master]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:production...master pull request from master to production]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Tag production branch with appropriate release name.<br />
<br />
<br />
git checkout production<br />
git tag -a WSXXX<br />
<br />
= Links =<br />
* [http://staging.wormbase.org staging site for testing]<br />
* [https://github.com/WormBase/website github repository]<br />
* [https://github.com/WormBase/website/issues github issue tracker]<br />
* [https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing workflow diagram]<br />
<br />
[[Category:Development General (Web Dev)]]<br />
[[Category:Getting Started (Web Dev)]]</div>Acabunochttps://wiki.wormbase.org/index.php?title=Development_workflow_-_webdev&diff=24289Development workflow - webdev2014-07-29T18:49:29Z<p>Acabunoc: /* Is my code ready for review? */</p>
<hr />
<div>This page describes the development model used by the web development team at WormBase using git as our version control system. This includes our branching strategy and release management. We use git and GitHub to help us manage development.<br />
<br />
= Overview Diagram =<br />
[[File:Git_Workflow_-_WormBase4.png]]<br />
<br />
[https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing Editable version of the diagram]<br />
<br />
= Contributing =<br />
<br />
Whenever you begin work on a new issue you should create a new branch for it. Any new major features should branch off <code>staging</code>. Once the feature is ready for testing, it can be merged back into <code>staging</code>. These aren't necessarily branches in the main repository - they can be local, or on a developer's fork. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Branch_stratgey Read more on our branching strategy]<br />
<br />
git checkout -b myFeature staging<br />
<br />
Now you can make your changes and commit some code. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Commit_Messages Read more on commit messages]<br />
git add /PATH/TO/UPDATED/FILE<br />
git commit -m "Descriptive commit message"<br />
<br />
When you're ready, you can push your branch to GitHub<br />
<br />
git push origin myFeature<br />
<br />
Continue making changes until your code is ready for a code review. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Is_my_code_ready_for_review.3F Is my code ready for review?]<br />
<br />
When your code is ready, go to GitHub and create a Pull Request. [http://nathanhoad.net/git-workflow-forks-remotes-and-pull-requests More info on Pull Requests.]<br />
<br />
# Go to the repository where you pushed your changes<br />
# Switch to your branch (myFeature)<br />
# Click the green '''Compare & review''' button<br />
# After reviewing all the changes, click on '''Create pull request''' in the header to send the pull request<br />
# In the description, write a short summary of the issues and changes made along with some links for testing [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#What_info_should_I_include_in_a_Pull_Request.3F What info should I include in a Pull Request?]<br />
<br />
Wait for another member of the web development team to review and merge your pull request. If more changes are requested, you can push more commits to the same branch and it will be added to the pull request.<br />
<br />
Once your pull request is merged, locally bring in the changes and delete your issue branch<br />
git checkout staging<br />
git pull<br />
git branch -d myFeature<br />
<br />
Go to the original github issue:<br />
# Add the '''Under testing''' label to your issue<br />
# Comment on the issue to notify all involved that it is ready for testing. Add links for testing for the ease of testers.<br />
# Another member of the WormBase group will close the issue once they have tested it<br />
<br />
== Is my code ready for review? == <br />
<br />
Before you send a Pull Request, please make sure you have completed the following:<br />
<br />
* Written tests (API tests or REST tests) demonstrating the problem in the issue. [http://wiki.wormbase.org/index.php/Unit_Testing More info on testing]<br />
* Fix the problem (ie pass the tests)<br />
* Complete the issue as much as possible without curators seeing an example<br />
* Code style meeting the [http://wiki.wormbase.org/index.php/Coding_standards WormBase coding standards] (indentation, comments, no debug statements)<br />
<br />
== What info should I include in a Pull Request? ==<br />
<br />
To help your reviewer understand your code, please try to include the following in the Pull Request description<br />
<br />
* A link to the issue being addressed<br />
* Short summary of the problem<br />
* Some links to use for testing<br />
* Any other information that may be needed to testing (ie wormbase_local.conf changes, extra files needed, etc)<br />
<br />
== Commit Messages ==<br />
git commit -m "COMMIT MESSAGE GOES HERE"<br />
<br />
Keep your commit message as descriptive as possible, reference any issues affected, close any this resolves:<br />
This is a summary of my commit.<br />
* here is a breakdown of the different changes<br />
* mention github users (@tharris) when appropriate<br />
* related to #YYY<br />
* fix #XXX<br />
<br />
Here is a template originally written by Tim Pope at tpope.net:<br />
<pre><br />
Short (50 chars or less) summary of changes<br />
<br />
More detailed explanatory text, if necessary. Wrap it to about 72<br />
characters or so. In some contexts, the first line is treated as the<br />
subject of an email and the rest of the text as the body. The blank<br />
line separating the summary from the body is critical (unless you omit<br />
the body entirely); tools like rebase can get confused if you run the<br />
two together.<br />
<br />
Further paragraphs come after blank lines.<br />
<br />
- Bullet points are okay, too<br />
<br />
- Typically a hyphen or asterisk is used for the bullet, preceded by a<br />
single space, with blank lines in between, but conventions vary here<br />
</pre><br />
<br />
= Testing & Code Review =<br />
There are two levels of review in our workflow.<br />
<br />
# Code review: At the pull request level, before code goes live on staging.wormbase.org<br />
# At the issue level, before closing an issue<br />
<br />
== Code Review: Pull Requests ==<br />
This level of testing is typically a code review before a Pull Request is merged into the staging branch. All members of the core development team are expected to keep an eye on the open Pull Requests and reviewing the ones they are most familiar with. Pull requests waiting for review should be left untouched for longer than two days after being assigned. <br />
<br />
* Test out the pull request (check out the branch)<br />
* Take a quick look at the code (are there comments? anything obvious missing)<br />
* Leave a comment on the PR if you notice anything that needs to be fixed<br />
* Merge the PR if you think it looks good<br />
<br />
== Testing: Issues ==<br />
All issues need to be tested and closed by at least one person who is not the developer who made the change. Ideally, it would be the curator asking for the feature/fix.<br />
<br />
'''If you would like to help test''':<br />
* Look at the [https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']. <br />
* All the changes for these issues are available for testing on [http://staging.wormbase.org staging.wormbase.org].<br />
* You can test out the changes and leave any feedback you have in the issue comments. <br />
* If you think this feature/fix is ready for production, you can '''remove the 'under testing' label''', or '''close the issue'''.<br />
<br />
= Branch Strategy =<br />
We use branches to help with our release management, testing strategy, and helping with parallel development among the team.<br />
<br />
== Main branches ==<br />
Inside the <code>WormBase/website</code> repository, there are three main branches: <code>master</code>, <code>staging</code> and <code>production</code>.<br />
<br />
* <code>master</code>: current, stable code. All new changes brought into master have been tested on [http://staging.wormbase.org staging.wormbase.org] and approved by either the curator requesting the change, or the development lead.<br />
<br />
* <code>staging</code>: any features/changes ready for testing should be pushed to the <code>staging</code> branch. This code gets pushed nightly to [http://staging.wormbase.org staging.wormbase.org].<br />
<br />
* <code>production</code>: the code currently in production. Branched off of <code>master</code> at each release.<br />
<br />
== Supporting branches == <br />
Other types of branches used can include feature branches and hotfixes. These branches are only intended to live until the new feature is merged into <code>staging</code> or the fix is completed.<br />
<br />
<br />
=== Feature branches ===<br />
Any new major features should branch off <code>staging</code>. Once the feature is ready for testing, it can be merged back into <code>staging</code>. These aren't necessarily branches in the main repository - can be local, or on a developer's fork.<br />
<br />
<br />
==== Testing issues ====<br />
All issues need to be tested and closed by at least one person who is not the developer who made the change. Ideally, it would be the curator asking for the feature/fix.<br />
<br />
'''If you would like to help test''':<br />
* Look at the [https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']. <br />
* All the changes for these issues are available for testing on [http://staging.wormbase.org staging.wormbase.org].<br />
<br />
'''If you are not the developer who pushed the code for this issue''':<br />
* You can test out the changes and leave any feedback you have in the issue comments. <br />
* If you think this feature/fix is ready for production, you can '''remove the 'under testing' label''', or '''close the issue'''.<br />
<br />
==== Moving a feature to <code>master</code> (pass testing) ====<br />
First, check to see which issues are currently being tested:<br />
[https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']<br />
<br />
If this list is '''empty''', <code>staging</code> can be merged onto the <code>master</code>.<br />
<br />
In github, create a [https://github.com/WormBase/website/pull/new/staging pull request for staging]. Look at the '''Commits''' and '''Files changes'''. In the comment, summary all the features/issues introduced and make sure they are stable. Click on '''send pull request'''.<br />
<br />
Once the pull request is reviewed, it can be merged into the master branch.<br />
<br />
=== Hotfixes ===<br />
If a major bugfix is needed in production, create a hotfix branch from production. When finished, the branch needs to be merged back into <code>production</code> and <code>staging</code><br />
<br />
==== Begining a fix ====<br />
git checkout -b hotfix-issXXX production<br />
<br />
Fix the bug and commit the fix in one or more commits. Reference the github issue:<br />
git commit -m "Severe production bug<br />
* search redirecting to home page<br />
* fix #XXX"<br />
<br />
==== Closing the fix ====<br />
The fix needs to be merged back to both <code>production</code> and <code>staging</code><br />
git checkout staging<br />
git merge hotfix-issXXX<br />
<br />
git checkout production<br />
git merge hotfix-issXXX<br />
<br />
<br />
= Development Timeline =<br />
<br />
See: [https://docs.google.com/document/d/1zIOm95tV9A14n9xnkPkMgiOTGcOIzx161y9UbDZvfW4/pub WormBase Release Workflow]<br />
<br />
= Release Management =<br />
When production is ready to updated for release WSXXX:<br />
<br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:master...staging pull request from staging to master]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:production...master pull request from master to production]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Tag production branch with appropriate release name.<br />
<br />
<br />
git checkout production<br />
git tag -a WSXXX<br />
<br />
= Links =<br />
* [http://staging.wormbase.org staging site for testing]<br />
* [https://github.com/WormBase/website github repository]<br />
* [https://github.com/WormBase/website/issues github issue tracker]<br />
* [https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing workflow diagram]<br />
<br />
[[Category:Development General (Web Dev)]]<br />
[[Category:Getting Started (Web Dev)]]</div>Acabunochttps://wiki.wormbase.org/index.php?title=Development_workflow_-_webdev&diff=24288Development workflow - webdev2014-07-29T18:47:03Z<p>Acabunoc: /* Contributing */</p>
<hr />
<div>This page describes the development model used by the web development team at WormBase using git as our version control system. This includes our branching strategy and release management. We use git and GitHub to help us manage development.<br />
<br />
= Overview Diagram =<br />
[[File:Git_Workflow_-_WormBase4.png]]<br />
<br />
[https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing Editable version of the diagram]<br />
<br />
= Contributing =<br />
<br />
Whenever you begin work on a new issue you should create a new branch for it. Any new major features should branch off <code>staging</code>. Once the feature is ready for testing, it can be merged back into <code>staging</code>. These aren't necessarily branches in the main repository - they can be local, or on a developer's fork. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Branch_stratgey Read more on our branching strategy]<br />
<br />
git checkout -b myFeature staging<br />
<br />
Now you can make your changes and commit some code. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Commit_Messages Read more on commit messages]<br />
git add /PATH/TO/UPDATED/FILE<br />
git commit -m "Descriptive commit message"<br />
<br />
When you're ready, you can push your branch to GitHub<br />
<br />
git push origin myFeature<br />
<br />
Continue making changes until your code is ready for a code review. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Is_my_code_ready_for_review.3F Is my code ready for review?]<br />
<br />
When your code is ready, go to GitHub and create a Pull Request. [http://nathanhoad.net/git-workflow-forks-remotes-and-pull-requests More info on Pull Requests.]<br />
<br />
# Go to the repository where you pushed your changes<br />
# Switch to your branch (myFeature)<br />
# Click the green '''Compare & review''' button<br />
# After reviewing all the changes, click on '''Create pull request''' in the header to send the pull request<br />
# In the description, write a short summary of the issues and changes made along with some links for testing [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#What_info_should_I_include_in_a_Pull_Request.3F What info should I include in a Pull Request?]<br />
<br />
Wait for another member of the web development team to review and merge your pull request. If more changes are requested, you can push more commits to the same branch and it will be added to the pull request.<br />
<br />
Once your pull request is merged, locally bring in the changes and delete your issue branch<br />
git checkout staging<br />
git pull<br />
git branch -d myFeature<br />
<br />
Go to the original github issue:<br />
# Add the '''Under testing''' label to your issue<br />
# Comment on the issue to notify all involved that it is ready for testing. Add links for testing for the ease of testers.<br />
# Another member of the WormBase group will close the issue once they have tested it<br />
<br />
== Is my code ready for review? == <br />
<br />
* Have written tests demonstrating the problem in the issue<br />
* Fix the problem (ie pass the tests)<br />
* Complete the issue as much as possible without curators seeing an example<br />
* Code style meeting the [http://wiki.wormbase.org/index.php/Coding_standards WormBase standards] (indentation, comments, no debug statements)<br />
<br />
== What info should I include in a Pull Request? ==<br />
<br />
To help your reviewer understand your code, please try to include the following in the Pull Request description<br />
<br />
* A link to the issue being addressed<br />
* Short summary of the problem<br />
* Some links to use for testing<br />
* Any other information that may be needed to testing (ie wormbase_local.conf changes, extra files needed, etc)<br />
<br />
== Commit Messages ==<br />
git commit -m "COMMIT MESSAGE GOES HERE"<br />
<br />
Keep your commit message as descriptive as possible, reference any issues affected, close any this resolves:<br />
This is a summary of my commit.<br />
* here is a breakdown of the different changes<br />
* mention github users (@tharris) when appropriate<br />
* related to #YYY<br />
* fix #XXX<br />
<br />
Here is a template originally written by Tim Pope at tpope.net:<br />
<pre><br />
Short (50 chars or less) summary of changes<br />
<br />
More detailed explanatory text, if necessary. Wrap it to about 72<br />
characters or so. In some contexts, the first line is treated as the<br />
subject of an email and the rest of the text as the body. The blank<br />
line separating the summary from the body is critical (unless you omit<br />
the body entirely); tools like rebase can get confused if you run the<br />
two together.<br />
<br />
Further paragraphs come after blank lines.<br />
<br />
- Bullet points are okay, too<br />
<br />
- Typically a hyphen or asterisk is used for the bullet, preceded by a<br />
single space, with blank lines in between, but conventions vary here<br />
</pre><br />
<br />
= Testing & Code Review =<br />
There are two levels of review in our workflow.<br />
<br />
# Code review: At the pull request level, before code goes live on staging.wormbase.org<br />
# At the issue level, before closing an issue<br />
<br />
== Code Review: Pull Requests ==<br />
This level of testing is typically a code review before a Pull Request is merged into the staging branch. All members of the core development team are expected to keep an eye on the open Pull Requests and reviewing the ones they are most familiar with. Pull requests waiting for review should be left untouched for longer than two days after being assigned. <br />
<br />
* Test out the pull request (check out the branch)<br />
* Take a quick look at the code (are there comments? anything obvious missing)<br />
* Leave a comment on the PR if you notice anything that needs to be fixed<br />
* Merge the PR if you think it looks good<br />
<br />
== Testing: Issues ==<br />
All issues need to be tested and closed by at least one person who is not the developer who made the change. Ideally, it would be the curator asking for the feature/fix.<br />
<br />
'''If you would like to help test''':<br />
* Look at the [https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']. <br />
* All the changes for these issues are available for testing on [http://staging.wormbase.org staging.wormbase.org].<br />
* You can test out the changes and leave any feedback you have in the issue comments. <br />
* If you think this feature/fix is ready for production, you can '''remove the 'under testing' label''', or '''close the issue'''.<br />
<br />
= Branch Strategy =<br />
We use branches to help with our release management, testing strategy, and helping with parallel development among the team.<br />
<br />
== Main branches ==<br />
Inside the <code>WormBase/website</code> repository, there are three main branches: <code>master</code>, <code>staging</code> and <code>production</code>.<br />
<br />
* <code>master</code>: current, stable code. All new changes brought into master have been tested on [http://staging.wormbase.org staging.wormbase.org] and approved by either the curator requesting the change, or the development lead.<br />
<br />
* <code>staging</code>: any features/changes ready for testing should be pushed to the <code>staging</code> branch. This code gets pushed nightly to [http://staging.wormbase.org staging.wormbase.org].<br />
<br />
* <code>production</code>: the code currently in production. Branched off of <code>master</code> at each release.<br />
<br />
== Supporting branches == <br />
Other types of branches used can include feature branches and hotfixes. These branches are only intended to live until the new feature is merged into <code>staging</code> or the fix is completed.<br />
<br />
<br />
=== Feature branches ===<br />
Any new major features should branch off <code>staging</code>. Once the feature is ready for testing, it can be merged back into <code>staging</code>. These aren't necessarily branches in the main repository - can be local, or on a developer's fork.<br />
<br />
<br />
==== Testing issues ====<br />
All issues need to be tested and closed by at least one person who is not the developer who made the change. Ideally, it would be the curator asking for the feature/fix.<br />
<br />
'''If you would like to help test''':<br />
* Look at the [https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']. <br />
* All the changes for these issues are available for testing on [http://staging.wormbase.org staging.wormbase.org].<br />
<br />
'''If you are not the developer who pushed the code for this issue''':<br />
* You can test out the changes and leave any feedback you have in the issue comments. <br />
* If you think this feature/fix is ready for production, you can '''remove the 'under testing' label''', or '''close the issue'''.<br />
<br />
==== Moving a feature to <code>master</code> (pass testing) ====<br />
First, check to see which issues are currently being tested:<br />
[https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']<br />
<br />
If this list is '''empty''', <code>staging</code> can be merged onto the <code>master</code>.<br />
<br />
In github, create a [https://github.com/WormBase/website/pull/new/staging pull request for staging]. Look at the '''Commits''' and '''Files changes'''. In the comment, summary all the features/issues introduced and make sure they are stable. Click on '''send pull request'''.<br />
<br />
Once the pull request is reviewed, it can be merged into the master branch.<br />
<br />
=== Hotfixes ===<br />
If a major bugfix is needed in production, create a hotfix branch from production. When finished, the branch needs to be merged back into <code>production</code> and <code>staging</code><br />
<br />
==== Begining a fix ====<br />
git checkout -b hotfix-issXXX production<br />
<br />
Fix the bug and commit the fix in one or more commits. Reference the github issue:<br />
git commit -m "Severe production bug<br />
* search redirecting to home page<br />
* fix #XXX"<br />
<br />
==== Closing the fix ====<br />
The fix needs to be merged back to both <code>production</code> and <code>staging</code><br />
git checkout staging<br />
git merge hotfix-issXXX<br />
<br />
git checkout production<br />
git merge hotfix-issXXX<br />
<br />
<br />
= Development Timeline =<br />
<br />
See: [https://docs.google.com/document/d/1zIOm95tV9A14n9xnkPkMgiOTGcOIzx161y9UbDZvfW4/pub WormBase Release Workflow]<br />
<br />
= Release Management =<br />
When production is ready to updated for release WSXXX:<br />
<br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:master...staging pull request from staging to master]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:production...master pull request from master to production]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Tag production branch with appropriate release name.<br />
<br />
<br />
git checkout production<br />
git tag -a WSXXX<br />
<br />
= Links =<br />
* [http://staging.wormbase.org staging site for testing]<br />
* [https://github.com/WormBase/website github repository]<br />
* [https://github.com/WormBase/website/issues github issue tracker]<br />
* [https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing workflow diagram]<br />
<br />
[[Category:Development General (Web Dev)]]<br />
[[Category:Getting Started (Web Dev)]]</div>Acabunochttps://wiki.wormbase.org/index.php?title=Development_workflow_-_webdev&diff=24287Development workflow - webdev2014-07-29T18:46:28Z<p>Acabunoc: /* Contributing */</p>
<hr />
<div>This page describes the development model used by the web development team at WormBase using git as our version control system. This includes our branching strategy and release management. We use git and GitHub to help us manage development.<br />
<br />
= Overview Diagram =<br />
[[File:Git_Workflow_-_WormBase4.png]]<br />
<br />
[https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing Editable version of the diagram]<br />
<br />
= Contributing =<br />
<br />
Whenever you begin work on a new issue you should create a new branch for it. Any new major features should branch off <code>staging</code>. Once the feature is ready for testing, it can be merged back into <code>staging</code>. These aren't necessarily branches in the main repository - they can be local, or on a developer's fork. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Branch_stratgey Read more on our branching strategy]<br />
<br />
git checkout -b myFeature staging<br />
<br />
Now you can make your changes and commit some code. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Commit_Messages Read more on commit messages]<br />
git add /PATH/TO/UPDATED/FILE<br />
git commit -m "Descriptive commit message"<br />
<br />
When you're ready, you can push your branch to GitHub<br />
<br />
git push origin myFeature<br />
<br />
Continue making changes until your code is ready for a code review. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Is_my_code_ready_for_review.3F Is my code ready for review?]<br />
<br />
When your code is ready, go to GitHub and create a Pull Request. [http://nathanhoad.net/git-workflow-forks-remotes-and-pull-requests More info on Pull Requests.]<br />
<br />
# Go to the repository where you pushed your changes<br />
# Switch to your branch (myFeature)<br />
# Click the green '''Compare & review''' button<br />
# After reviewing all the changes, click on '''Create pull request''' in the header to send the pull request<br />
# In the description, write a short summary of the issues and changes made along with some links for testing<br />
<br />
Wait for another member of the web development team to review and merge your pull request. If more changes are requested, you can push more commits to the same branch and it will be added to the pull request.<br />
<br />
Once your pull request is merged, locally bring in the changes and delete your issue branch<br />
git checkout staging<br />
git pull<br />
git branch -d myFeature<br />
<br />
Go to the original github issue:<br />
# Add the '''Under testing''' label to your issue<br />
# Comment on the issue to notify all involved that it is ready for testing. Add links for testing for the ease of testers.<br />
# Another member of the WormBase group will close the issue once they have tested it<br />
<br />
== Is my code ready for review? == <br />
<br />
* Have written tests demonstrating the problem in the issue<br />
* Fix the problem (ie pass the tests)<br />
* Complete the issue as much as possible without curators seeing an example<br />
* Code style meeting the [http://wiki.wormbase.org/index.php/Coding_standards WormBase standards] (indentation, comments, no debug statements)<br />
<br />
== What info should I include in a Pull Request? ==<br />
<br />
To help your reviewer understand your code, please try to include the following in the Pull Request description<br />
<br />
* A link to the issue being addressed<br />
* Short summary of the problem<br />
* Some links to use for testing<br />
* Any other information that may be needed to testing (ie wormbase_local.conf changes, extra files needed, etc)<br />
<br />
== Commit Messages ==<br />
git commit -m "COMMIT MESSAGE GOES HERE"<br />
<br />
Keep your commit message as descriptive as possible, reference any issues affected, close any this resolves:<br />
This is a summary of my commit.<br />
* here is a breakdown of the different changes<br />
* mention github users (@tharris) when appropriate<br />
* related to #YYY<br />
* fix #XXX<br />
<br />
Here is a template originally written by Tim Pope at tpope.net:<br />
<pre><br />
Short (50 chars or less) summary of changes<br />
<br />
More detailed explanatory text, if necessary. Wrap it to about 72<br />
characters or so. In some contexts, the first line is treated as the<br />
subject of an email and the rest of the text as the body. The blank<br />
line separating the summary from the body is critical (unless you omit<br />
the body entirely); tools like rebase can get confused if you run the<br />
two together.<br />
<br />
Further paragraphs come after blank lines.<br />
<br />
- Bullet points are okay, too<br />
<br />
- Typically a hyphen or asterisk is used for the bullet, preceded by a<br />
single space, with blank lines in between, but conventions vary here<br />
</pre><br />
<br />
= Testing & Code Review =<br />
There are two levels of review in our workflow.<br />
<br />
# Code review: At the pull request level, before code goes live on staging.wormbase.org<br />
# At the issue level, before closing an issue<br />
<br />
== Code Review: Pull Requests ==<br />
This level of testing is typically a code review before a Pull Request is merged into the staging branch. All members of the core development team are expected to keep an eye on the open Pull Requests and reviewing the ones they are most familiar with. Pull requests waiting for review should be left untouched for longer than two days after being assigned. <br />
<br />
* Test out the pull request (check out the branch)<br />
* Take a quick look at the code (are there comments? anything obvious missing)<br />
* Leave a comment on the PR if you notice anything that needs to be fixed<br />
* Merge the PR if you think it looks good<br />
<br />
== Testing: Issues ==<br />
All issues need to be tested and closed by at least one person who is not the developer who made the change. Ideally, it would be the curator asking for the feature/fix.<br />
<br />
'''If you would like to help test''':<br />
* Look at the [https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']. <br />
* All the changes for these issues are available for testing on [http://staging.wormbase.org staging.wormbase.org].<br />
* You can test out the changes and leave any feedback you have in the issue comments. <br />
* If you think this feature/fix is ready for production, you can '''remove the 'under testing' label''', or '''close the issue'''.<br />
<br />
= Branch Strategy =<br />
We use branches to help with our release management, testing strategy, and helping with parallel development among the team.<br />
<br />
== Main branches ==<br />
Inside the <code>WormBase/website</code> repository, there are three main branches: <code>master</code>, <code>staging</code> and <code>production</code>.<br />
<br />
* <code>master</code>: current, stable code. All new changes brought into master have been tested on [http://staging.wormbase.org staging.wormbase.org] and approved by either the curator requesting the change, or the development lead.<br />
<br />
* <code>staging</code>: any features/changes ready for testing should be pushed to the <code>staging</code> branch. This code gets pushed nightly to [http://staging.wormbase.org staging.wormbase.org].<br />
<br />
* <code>production</code>: the code currently in production. Branched off of <code>master</code> at each release.<br />
<br />
== Supporting branches == <br />
Other types of branches used can include feature branches and hotfixes. These branches are only intended to live until the new feature is merged into <code>staging</code> or the fix is completed.<br />
<br />
<br />
=== Feature branches ===<br />
Any new major features should branch off <code>staging</code>. Once the feature is ready for testing, it can be merged back into <code>staging</code>. These aren't necessarily branches in the main repository - can be local, or on a developer's fork.<br />
<br />
<br />
==== Testing issues ====<br />
All issues need to be tested and closed by at least one person who is not the developer who made the change. Ideally, it would be the curator asking for the feature/fix.<br />
<br />
'''If you would like to help test''':<br />
* Look at the [https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']. <br />
* All the changes for these issues are available for testing on [http://staging.wormbase.org staging.wormbase.org].<br />
<br />
'''If you are not the developer who pushed the code for this issue''':<br />
* You can test out the changes and leave any feedback you have in the issue comments. <br />
* If you think this feature/fix is ready for production, you can '''remove the 'under testing' label''', or '''close the issue'''.<br />
<br />
==== Moving a feature to <code>master</code> (pass testing) ====<br />
First, check to see which issues are currently being tested:<br />
[https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']<br />
<br />
If this list is '''empty''', <code>staging</code> can be merged onto the <code>master</code>.<br />
<br />
In github, create a [https://github.com/WormBase/website/pull/new/staging pull request for staging]. Look at the '''Commits''' and '''Files changes'''. In the comment, summary all the features/issues introduced and make sure they are stable. Click on '''send pull request'''.<br />
<br />
Once the pull request is reviewed, it can be merged into the master branch.<br />
<br />
=== Hotfixes ===<br />
If a major bugfix is needed in production, create a hotfix branch from production. When finished, the branch needs to be merged back into <code>production</code> and <code>staging</code><br />
<br />
==== Begining a fix ====<br />
git checkout -b hotfix-issXXX production<br />
<br />
Fix the bug and commit the fix in one or more commits. Reference the github issue:<br />
git commit -m "Severe production bug<br />
* search redirecting to home page<br />
* fix #XXX"<br />
<br />
==== Closing the fix ====<br />
The fix needs to be merged back to both <code>production</code> and <code>staging</code><br />
git checkout staging<br />
git merge hotfix-issXXX<br />
<br />
git checkout production<br />
git merge hotfix-issXXX<br />
<br />
<br />
= Development Timeline =<br />
<br />
See: [https://docs.google.com/document/d/1zIOm95tV9A14n9xnkPkMgiOTGcOIzx161y9UbDZvfW4/pub WormBase Release Workflow]<br />
<br />
= Release Management =<br />
When production is ready to updated for release WSXXX:<br />
<br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:master...staging pull request from staging to master]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:production...master pull request from master to production]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Tag production branch with appropriate release name.<br />
<br />
<br />
git checkout production<br />
git tag -a WSXXX<br />
<br />
= Links =<br />
* [http://staging.wormbase.org staging site for testing]<br />
* [https://github.com/WormBase/website github repository]<br />
* [https://github.com/WormBase/website/issues github issue tracker]<br />
* [https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing workflow diagram]<br />
<br />
[[Category:Development General (Web Dev)]]<br />
[[Category:Getting Started (Web Dev)]]</div>Acabunochttps://wiki.wormbase.org/index.php?title=Development_workflow_-_webdev&diff=24286Development workflow - webdev2014-07-29T18:43:50Z<p>Acabunoc: /* Contributing */</p>
<hr />
<div>This page describes the development model used by the web development team at WormBase using git as our version control system. This includes our branching strategy and release management. We use git and GitHub to help us manage development.<br />
<br />
= Overview Diagram =<br />
[[File:Git_Workflow_-_WormBase4.png]]<br />
<br />
[https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing Editable version of the diagram]<br />
<br />
= Contributing =<br />
<br />
Whenever you begin work on a new issue you should create a new branch for it. Any new major features should branch off <code>staging</code>. Once the feature is ready for testing, it can be merged back into <code>staging</code>. These aren't necessarily branches in the main repository - they can be local, or on a developer's fork. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Branch_stratgey Read more on our branching strategy]<br />
<br />
git checkout -b myFeature staging<br />
<br />
Now you can make your changes and commit some code. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Commit_Messages Read more on commit messages]<br />
git add /PATH/TO/UPDATED/FILE<br />
git commit -m "Descriptive commit message"<br />
<br />
When you're ready, you can push your branch to GitHub<br />
<br />
git push origin myFeature<br />
<br />
Continue making changes until your code is ready for a code review. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Is_my_code_ready_for_review.3F Is my code ready for review?]<br />
<br />
When your code is ready, go to GitHub and create a Pull Request. [http://nathanhoad.net/git-workflow-forks-remotes-and-pull-requests More info on Pull Requests.]<br />
<br />
# Go to the repository where you pushed your changes<br />
# Switch to your branch (myFeature)<br />
# Click the green '''Compare & review''' button<br />
# After reviewing all the changes, click on '''Create pull request''' in the header to send the pull request<br />
# In the description, write a short summary of the issues and changes made along with some links for testing<br />
<br />
Wait for another member of the web development team to review and merge your pull request. If more changes are requested, you can push more commits to the same branch and it will be added to the pull request.<br />
<br />
Once your pull request is merged, locally bring in the changes and delete your issue branch<br />
git checkout staging<br />
git pull<br />
git branch -d myFeature<br />
<br />
Go to the original github issue:<br />
# Add the '''Under testing''' label to your issue<br />
# Comment on the issue to notify all involved that it is ready for testing. Add links for testing for the ease of testers.<br />
# Another member of the WormBase group will close the issue once they have tested it<br />
<br />
== Is my code ready for review? == <br />
<br />
* Have written tests demonstrating the problem in the issue<br />
* Fix the problem (ie pass the tests)<br />
* Complete the issue as much as possible without curators seeing an example<br />
* Code style meeting the [http://wiki.wormbase.org/index.php/Coding_standards WormBase standards] (indentation, comments, no debug statements)<br />
<br />
== Commit Messages ==<br />
git commit -m "COMMIT MESSAGE GOES HERE"<br />
<br />
Keep your commit message as descriptive as possible, reference any issues affected, close any this resolves:<br />
This is a summary of my commit.<br />
* here is a breakdown of the different changes<br />
* mention github users (@tharris) when appropriate<br />
* related to #YYY<br />
* fix #XXX<br />
<br />
Here is a template originally written by Tim Pope at tpope.net:<br />
<pre><br />
Short (50 chars or less) summary of changes<br />
<br />
More detailed explanatory text, if necessary. Wrap it to about 72<br />
characters or so. In some contexts, the first line is treated as the<br />
subject of an email and the rest of the text as the body. The blank<br />
line separating the summary from the body is critical (unless you omit<br />
the body entirely); tools like rebase can get confused if you run the<br />
two together.<br />
<br />
Further paragraphs come after blank lines.<br />
<br />
- Bullet points are okay, too<br />
<br />
- Typically a hyphen or asterisk is used for the bullet, preceded by a<br />
single space, with blank lines in between, but conventions vary here<br />
</pre><br />
<br />
= Testing & Code Review =<br />
There are two levels of review in our workflow.<br />
<br />
# Code review: At the pull request level, before code goes live on staging.wormbase.org<br />
# At the issue level, before closing an issue<br />
<br />
== Code Review: Pull Requests ==<br />
This level of testing is typically a code review before a Pull Request is merged into the staging branch. All members of the core development team are expected to keep an eye on the open Pull Requests and reviewing the ones they are most familiar with. Pull requests waiting for review should be left untouched for longer than two days after being assigned. <br />
<br />
* Test out the pull request (check out the branch)<br />
* Take a quick look at the code (are there comments? anything obvious missing)<br />
* Leave a comment on the PR if you notice anything that needs to be fixed<br />
* Merge the PR if you think it looks good<br />
<br />
== Testing: Issues ==<br />
All issues need to be tested and closed by at least one person who is not the developer who made the change. Ideally, it would be the curator asking for the feature/fix.<br />
<br />
'''If you would like to help test''':<br />
* Look at the [https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']. <br />
* All the changes for these issues are available for testing on [http://staging.wormbase.org staging.wormbase.org].<br />
* You can test out the changes and leave any feedback you have in the issue comments. <br />
* If you think this feature/fix is ready for production, you can '''remove the 'under testing' label''', or '''close the issue'''.<br />
<br />
= Branch Strategy =<br />
We use branches to help with our release management, testing strategy, and helping with parallel development among the team.<br />
<br />
== Main branches ==<br />
Inside the <code>WormBase/website</code> repository, there are three main branches: <code>master</code>, <code>staging</code> and <code>production</code>.<br />
<br />
* <code>master</code>: current, stable code. All new changes brought into master have been tested on [http://staging.wormbase.org staging.wormbase.org] and approved by either the curator requesting the change, or the development lead.<br />
<br />
* <code>staging</code>: any features/changes ready for testing should be pushed to the <code>staging</code> branch. This code gets pushed nightly to [http://staging.wormbase.org staging.wormbase.org].<br />
<br />
* <code>production</code>: the code currently in production. Branched off of <code>master</code> at each release.<br />
<br />
== Supporting branches == <br />
Other types of branches used can include feature branches and hotfixes. These branches are only intended to live until the new feature is merged into <code>staging</code> or the fix is completed.<br />
<br />
<br />
=== Feature branches ===<br />
Any new major features should branch off <code>staging</code>. Once the feature is ready for testing, it can be merged back into <code>staging</code>. These aren't necessarily branches in the main repository - can be local, or on a developer's fork.<br />
<br />
<br />
==== Testing issues ====<br />
All issues need to be tested and closed by at least one person who is not the developer who made the change. Ideally, it would be the curator asking for the feature/fix.<br />
<br />
'''If you would like to help test''':<br />
* Look at the [https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']. <br />
* All the changes for these issues are available for testing on [http://staging.wormbase.org staging.wormbase.org].<br />
<br />
'''If you are not the developer who pushed the code for this issue''':<br />
* You can test out the changes and leave any feedback you have in the issue comments. <br />
* If you think this feature/fix is ready for production, you can '''remove the 'under testing' label''', or '''close the issue'''.<br />
<br />
==== Moving a feature to <code>master</code> (pass testing) ====<br />
First, check to see which issues are currently being tested:<br />
[https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']<br />
<br />
If this list is '''empty''', <code>staging</code> can be merged onto the <code>master</code>.<br />
<br />
In github, create a [https://github.com/WormBase/website/pull/new/staging pull request for staging]. Look at the '''Commits''' and '''Files changes'''. In the comment, summary all the features/issues introduced and make sure they are stable. Click on '''send pull request'''.<br />
<br />
Once the pull request is reviewed, it can be merged into the master branch.<br />
<br />
=== Hotfixes ===<br />
If a major bugfix is needed in production, create a hotfix branch from production. When finished, the branch needs to be merged back into <code>production</code> and <code>staging</code><br />
<br />
==== Begining a fix ====<br />
git checkout -b hotfix-issXXX production<br />
<br />
Fix the bug and commit the fix in one or more commits. Reference the github issue:<br />
git commit -m "Severe production bug<br />
* search redirecting to home page<br />
* fix #XXX"<br />
<br />
==== Closing the fix ====<br />
The fix needs to be merged back to both <code>production</code> and <code>staging</code><br />
git checkout staging<br />
git merge hotfix-issXXX<br />
<br />
git checkout production<br />
git merge hotfix-issXXX<br />
<br />
<br />
= Development Timeline =<br />
<br />
See: [https://docs.google.com/document/d/1zIOm95tV9A14n9xnkPkMgiOTGcOIzx161y9UbDZvfW4/pub WormBase Release Workflow]<br />
<br />
= Release Management =<br />
When production is ready to updated for release WSXXX:<br />
<br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:master...staging pull request from staging to master]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:production...master pull request from master to production]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Tag production branch with appropriate release name.<br />
<br />
<br />
git checkout production<br />
git tag -a WSXXX<br />
<br />
= Links =<br />
* [http://staging.wormbase.org staging site for testing]<br />
* [https://github.com/WormBase/website github repository]<br />
* [https://github.com/WormBase/website/issues github issue tracker]<br />
* [https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing workflow diagram]<br />
<br />
[[Category:Development General (Web Dev)]]<br />
[[Category:Getting Started (Web Dev)]]</div>Acabunochttps://wiki.wormbase.org/index.php?title=Development_workflow_-_webdev&diff=24285Development workflow - webdev2014-07-29T18:43:32Z<p>Acabunoc: /* Is my code ready for testing? */</p>
<hr />
<div>This page describes the development model used by the web development team at WormBase using git as our version control system. This includes our branching strategy and release management. We use git and GitHub to help us manage development.<br />
<br />
= Overview Diagram =<br />
[[File:Git_Workflow_-_WormBase4.png]]<br />
<br />
[https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing Editable version of the diagram]<br />
<br />
= Contributing =<br />
<br />
Whenever you begin work on a new issue you should create a new branch for it. Any new major features should branch off <code>staging</code>. Once the feature is ready for testing, it can be merged back into <code>staging</code>. These aren't necessarily branches in the main repository - they can be local, or on a developer's fork. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Branch_stratgey Read more on our branching strategy]<br />
<br />
git checkout -b myFeature staging<br />
<br />
Now you can make your changes and commit some code. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Commit_Messages Read more on commit messages]<br />
git add /PATH/TO/UPDATED/FILE<br />
git commit -m "Descriptive commit message"<br />
<br />
When you're ready, you can push your branch to GitHub<br />
<br />
git push origin myFeature<br />
<br />
Continue making changes until your code is ready for a code review. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Is_my_code_ready_for_testing.3F Is my code ready for a code review?]<br />
<br />
When your code is ready, go to GitHub and create a Pull Request. [http://nathanhoad.net/git-workflow-forks-remotes-and-pull-requests More info on Pull Requests.]<br />
<br />
# Go to the repository where you pushed your changes<br />
# Switch to your branch (myFeature)<br />
# Click the green '''Compare & review''' button<br />
# After reviewing all the changes, click on '''Create pull request''' in the header to send the pull request<br />
# In the description, write a short summary of the issues and changes made along with some links for testing<br />
<br />
Wait for another member of the web development team to review and merge your pull request. If more changes are requested, you can push more commits to the same branch and it will be added to the pull request.<br />
<br />
Once your pull request is merged, locally bring in the changes and delete your issue branch<br />
git checkout staging<br />
git pull<br />
git branch -d myFeature<br />
<br />
Go to the original github issue:<br />
# Add the '''Under testing''' label to your issue<br />
# Comment on the issue to notify all involved that it is ready for testing. Add links for testing for the ease of testers.<br />
# Another member of the WormBase group will close the issue once they have tested it<br />
<br />
== Is my code ready for review? == <br />
<br />
* Have written tests demonstrating the problem in the issue<br />
* Fix the problem (ie pass the tests)<br />
* Complete the issue as much as possible without curators seeing an example<br />
* Code style meeting the [http://wiki.wormbase.org/index.php/Coding_standards WormBase standards] (indentation, comments, no debug statements)<br />
<br />
== Commit Messages ==<br />
git commit -m "COMMIT MESSAGE GOES HERE"<br />
<br />
Keep your commit message as descriptive as possible, reference any issues affected, close any this resolves:<br />
This is a summary of my commit.<br />
* here is a breakdown of the different changes<br />
* mention github users (@tharris) when appropriate<br />
* related to #YYY<br />
* fix #XXX<br />
<br />
Here is a template originally written by Tim Pope at tpope.net:<br />
<pre><br />
Short (50 chars or less) summary of changes<br />
<br />
More detailed explanatory text, if necessary. Wrap it to about 72<br />
characters or so. In some contexts, the first line is treated as the<br />
subject of an email and the rest of the text as the body. The blank<br />
line separating the summary from the body is critical (unless you omit<br />
the body entirely); tools like rebase can get confused if you run the<br />
two together.<br />
<br />
Further paragraphs come after blank lines.<br />
<br />
- Bullet points are okay, too<br />
<br />
- Typically a hyphen or asterisk is used for the bullet, preceded by a<br />
single space, with blank lines in between, but conventions vary here<br />
</pre><br />
<br />
= Testing & Code Review =<br />
There are two levels of review in our workflow.<br />
<br />
# Code review: At the pull request level, before code goes live on staging.wormbase.org<br />
# At the issue level, before closing an issue<br />
<br />
== Code Review: Pull Requests ==<br />
This level of testing is typically a code review before a Pull Request is merged into the staging branch. All members of the core development team are expected to keep an eye on the open Pull Requests and reviewing the ones they are most familiar with. Pull requests waiting for review should be left untouched for longer than two days after being assigned. <br />
<br />
* Test out the pull request (check out the branch)<br />
* Take a quick look at the code (are there comments? anything obvious missing)<br />
* Leave a comment on the PR if you notice anything that needs to be fixed<br />
* Merge the PR if you think it looks good<br />
<br />
== Testing: Issues ==<br />
All issues need to be tested and closed by at least one person who is not the developer who made the change. Ideally, it would be the curator asking for the feature/fix.<br />
<br />
'''If you would like to help test''':<br />
* Look at the [https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']. <br />
* All the changes for these issues are available for testing on [http://staging.wormbase.org staging.wormbase.org].<br />
* You can test out the changes and leave any feedback you have in the issue comments. <br />
* If you think this feature/fix is ready for production, you can '''remove the 'under testing' label''', or '''close the issue'''.<br />
<br />
= Branch Strategy =<br />
We use branches to help with our release management, testing strategy, and helping with parallel development among the team.<br />
<br />
== Main branches ==<br />
Inside the <code>WormBase/website</code> repository, there are three main branches: <code>master</code>, <code>staging</code> and <code>production</code>.<br />
<br />
* <code>master</code>: current, stable code. All new changes brought into master have been tested on [http://staging.wormbase.org staging.wormbase.org] and approved by either the curator requesting the change, or the development lead.<br />
<br />
* <code>staging</code>: any features/changes ready for testing should be pushed to the <code>staging</code> branch. This code gets pushed nightly to [http://staging.wormbase.org staging.wormbase.org].<br />
<br />
* <code>production</code>: the code currently in production. Branched off of <code>master</code> at each release.<br />
<br />
== Supporting branches == <br />
Other types of branches used can include feature branches and hotfixes. These branches are only intended to live until the new feature is merged into <code>staging</code> or the fix is completed.<br />
<br />
<br />
=== Feature branches ===<br />
Any new major features should branch off <code>staging</code>. Once the feature is ready for testing, it can be merged back into <code>staging</code>. These aren't necessarily branches in the main repository - can be local, or on a developer's fork.<br />
<br />
<br />
==== Testing issues ====<br />
All issues need to be tested and closed by at least one person who is not the developer who made the change. Ideally, it would be the curator asking for the feature/fix.<br />
<br />
'''If you would like to help test''':<br />
* Look at the [https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']. <br />
* All the changes for these issues are available for testing on [http://staging.wormbase.org staging.wormbase.org].<br />
<br />
'''If you are not the developer who pushed the code for this issue''':<br />
* You can test out the changes and leave any feedback you have in the issue comments. <br />
* If you think this feature/fix is ready for production, you can '''remove the 'under testing' label''', or '''close the issue'''.<br />
<br />
==== Moving a feature to <code>master</code> (pass testing) ====<br />
First, check to see which issues are currently being tested:<br />
[https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']<br />
<br />
If this list is '''empty''', <code>staging</code> can be merged onto the <code>master</code>.<br />
<br />
In github, create a [https://github.com/WormBase/website/pull/new/staging pull request for staging]. Look at the '''Commits''' and '''Files changes'''. In the comment, summary all the features/issues introduced and make sure they are stable. Click on '''send pull request'''.<br />
<br />
Once the pull request is reviewed, it can be merged into the master branch.<br />
<br />
=== Hotfixes ===<br />
If a major bugfix is needed in production, create a hotfix branch from production. When finished, the branch needs to be merged back into <code>production</code> and <code>staging</code><br />
<br />
==== Begining a fix ====<br />
git checkout -b hotfix-issXXX production<br />
<br />
Fix the bug and commit the fix in one or more commits. Reference the github issue:<br />
git commit -m "Severe production bug<br />
* search redirecting to home page<br />
* fix #XXX"<br />
<br />
==== Closing the fix ====<br />
The fix needs to be merged back to both <code>production</code> and <code>staging</code><br />
git checkout staging<br />
git merge hotfix-issXXX<br />
<br />
git checkout production<br />
git merge hotfix-issXXX<br />
<br />
<br />
= Development Timeline =<br />
<br />
See: [https://docs.google.com/document/d/1zIOm95tV9A14n9xnkPkMgiOTGcOIzx161y9UbDZvfW4/pub WormBase Release Workflow]<br />
<br />
= Release Management =<br />
When production is ready to updated for release WSXXX:<br />
<br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:master...staging pull request from staging to master]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:production...master pull request from master to production]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Tag production branch with appropriate release name.<br />
<br />
<br />
git checkout production<br />
git tag -a WSXXX<br />
<br />
= Links =<br />
* [http://staging.wormbase.org staging site for testing]<br />
* [https://github.com/WormBase/website github repository]<br />
* [https://github.com/WormBase/website/issues github issue tracker]<br />
* [https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing workflow diagram]<br />
<br />
[[Category:Development General (Web Dev)]]<br />
[[Category:Getting Started (Web Dev)]]</div>Acabunochttps://wiki.wormbase.org/index.php?title=Development_workflow_-_webdev&diff=24284Development workflow - webdev2014-07-29T18:43:18Z<p>Acabunoc: /* Contributing */</p>
<hr />
<div>This page describes the development model used by the web development team at WormBase using git as our version control system. This includes our branching strategy and release management. We use git and GitHub to help us manage development.<br />
<br />
= Overview Diagram =<br />
[[File:Git_Workflow_-_WormBase4.png]]<br />
<br />
[https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing Editable version of the diagram]<br />
<br />
= Contributing =<br />
<br />
Whenever you begin work on a new issue you should create a new branch for it. Any new major features should branch off <code>staging</code>. Once the feature is ready for testing, it can be merged back into <code>staging</code>. These aren't necessarily branches in the main repository - they can be local, or on a developer's fork. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Branch_stratgey Read more on our branching strategy]<br />
<br />
git checkout -b myFeature staging<br />
<br />
Now you can make your changes and commit some code. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Commit_Messages Read more on commit messages]<br />
git add /PATH/TO/UPDATED/FILE<br />
git commit -m "Descriptive commit message"<br />
<br />
When you're ready, you can push your branch to GitHub<br />
<br />
git push origin myFeature<br />
<br />
Continue making changes until your code is ready for a code review. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Is_my_code_ready_for_testing.3F Is my code ready for a code review?]<br />
<br />
When your code is ready, go to GitHub and create a Pull Request. [http://nathanhoad.net/git-workflow-forks-remotes-and-pull-requests More info on Pull Requests.]<br />
<br />
# Go to the repository where you pushed your changes<br />
# Switch to your branch (myFeature)<br />
# Click the green '''Compare & review''' button<br />
# After reviewing all the changes, click on '''Create pull request''' in the header to send the pull request<br />
# In the description, write a short summary of the issues and changes made along with some links for testing<br />
<br />
Wait for another member of the web development team to review and merge your pull request. If more changes are requested, you can push more commits to the same branch and it will be added to the pull request.<br />
<br />
Once your pull request is merged, locally bring in the changes and delete your issue branch<br />
git checkout staging<br />
git pull<br />
git branch -d myFeature<br />
<br />
Go to the original github issue:<br />
# Add the '''Under testing''' label to your issue<br />
# Comment on the issue to notify all involved that it is ready for testing. Add links for testing for the ease of testers.<br />
# Another member of the WormBase group will close the issue once they have tested it<br />
<br />
== Is my code ready for testing? == <br />
<br />
* Have written tests demonstrating the problem in the issue<br />
* Fix the problem (ie pass the tests)<br />
* Complete the issue as much as possible without curators seeing an example<br />
* Code style meeting the [http://wiki.wormbase.org/index.php/Coding_standards WormBase standards] (indentation, comments, no debug statements)<br />
<br />
== Commit Messages ==<br />
git commit -m "COMMIT MESSAGE GOES HERE"<br />
<br />
Keep your commit message as descriptive as possible, reference any issues affected, close any this resolves:<br />
This is a summary of my commit.<br />
* here is a breakdown of the different changes<br />
* mention github users (@tharris) when appropriate<br />
* related to #YYY<br />
* fix #XXX<br />
<br />
Here is a template originally written by Tim Pope at tpope.net:<br />
<pre><br />
Short (50 chars or less) summary of changes<br />
<br />
More detailed explanatory text, if necessary. Wrap it to about 72<br />
characters or so. In some contexts, the first line is treated as the<br />
subject of an email and the rest of the text as the body. The blank<br />
line separating the summary from the body is critical (unless you omit<br />
the body entirely); tools like rebase can get confused if you run the<br />
two together.<br />
<br />
Further paragraphs come after blank lines.<br />
<br />
- Bullet points are okay, too<br />
<br />
- Typically a hyphen or asterisk is used for the bullet, preceded by a<br />
single space, with blank lines in between, but conventions vary here<br />
</pre><br />
<br />
= Testing & Code Review =<br />
There are two levels of review in our workflow.<br />
<br />
# Code review: At the pull request level, before code goes live on staging.wormbase.org<br />
# At the issue level, before closing an issue<br />
<br />
== Code Review: Pull Requests ==<br />
This level of testing is typically a code review before a Pull Request is merged into the staging branch. All members of the core development team are expected to keep an eye on the open Pull Requests and reviewing the ones they are most familiar with. Pull requests waiting for review should be left untouched for longer than two days after being assigned. <br />
<br />
* Test out the pull request (check out the branch)<br />
* Take a quick look at the code (are there comments? anything obvious missing)<br />
* Leave a comment on the PR if you notice anything that needs to be fixed<br />
* Merge the PR if you think it looks good<br />
<br />
== Testing: Issues ==<br />
All issues need to be tested and closed by at least one person who is not the developer who made the change. Ideally, it would be the curator asking for the feature/fix.<br />
<br />
'''If you would like to help test''':<br />
* Look at the [https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']. <br />
* All the changes for these issues are available for testing on [http://staging.wormbase.org staging.wormbase.org].<br />
* You can test out the changes and leave any feedback you have in the issue comments. <br />
* If you think this feature/fix is ready for production, you can '''remove the 'under testing' label''', or '''close the issue'''.<br />
<br />
= Branch Strategy =<br />
We use branches to help with our release management, testing strategy, and helping with parallel development among the team.<br />
<br />
== Main branches ==<br />
Inside the <code>WormBase/website</code> repository, there are three main branches: <code>master</code>, <code>staging</code> and <code>production</code>.<br />
<br />
* <code>master</code>: current, stable code. All new changes brought into master have been tested on [http://staging.wormbase.org staging.wormbase.org] and approved by either the curator requesting the change, or the development lead.<br />
<br />
* <code>staging</code>: any features/changes ready for testing should be pushed to the <code>staging</code> branch. This code gets pushed nightly to [http://staging.wormbase.org staging.wormbase.org].<br />
<br />
* <code>production</code>: the code currently in production. Branched off of <code>master</code> at each release.<br />
<br />
== Supporting branches == <br />
Other types of branches used can include feature branches and hotfixes. These branches are only intended to live until the new feature is merged into <code>staging</code> or the fix is completed.<br />
<br />
<br />
=== Feature branches ===<br />
Any new major features should branch off <code>staging</code>. Once the feature is ready for testing, it can be merged back into <code>staging</code>. These aren't necessarily branches in the main repository - can be local, or on a developer's fork.<br />
<br />
<br />
==== Testing issues ====<br />
All issues need to be tested and closed by at least one person who is not the developer who made the change. Ideally, it would be the curator asking for the feature/fix.<br />
<br />
'''If you would like to help test''':<br />
* Look at the [https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']. <br />
* All the changes for these issues are available for testing on [http://staging.wormbase.org staging.wormbase.org].<br />
<br />
'''If you are not the developer who pushed the code for this issue''':<br />
* You can test out the changes and leave any feedback you have in the issue comments. <br />
* If you think this feature/fix is ready for production, you can '''remove the 'under testing' label''', or '''close the issue'''.<br />
<br />
==== Moving a feature to <code>master</code> (pass testing) ====<br />
First, check to see which issues are currently being tested:<br />
[https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']<br />
<br />
If this list is '''empty''', <code>staging</code> can be merged onto the <code>master</code>.<br />
<br />
In github, create a [https://github.com/WormBase/website/pull/new/staging pull request for staging]. Look at the '''Commits''' and '''Files changes'''. In the comment, summary all the features/issues introduced and make sure they are stable. Click on '''send pull request'''.<br />
<br />
Once the pull request is reviewed, it can be merged into the master branch.<br />
<br />
=== Hotfixes ===<br />
If a major bugfix is needed in production, create a hotfix branch from production. When finished, the branch needs to be merged back into <code>production</code> and <code>staging</code><br />
<br />
==== Begining a fix ====<br />
git checkout -b hotfix-issXXX production<br />
<br />
Fix the bug and commit the fix in one or more commits. Reference the github issue:<br />
git commit -m "Severe production bug<br />
* search redirecting to home page<br />
* fix #XXX"<br />
<br />
==== Closing the fix ====<br />
The fix needs to be merged back to both <code>production</code> and <code>staging</code><br />
git checkout staging<br />
git merge hotfix-issXXX<br />
<br />
git checkout production<br />
git merge hotfix-issXXX<br />
<br />
<br />
= Development Timeline =<br />
<br />
See: [https://docs.google.com/document/d/1zIOm95tV9A14n9xnkPkMgiOTGcOIzx161y9UbDZvfW4/pub WormBase Release Workflow]<br />
<br />
= Release Management =<br />
When production is ready to updated for release WSXXX:<br />
<br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:master...staging pull request from staging to master]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:production...master pull request from master to production]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Tag production branch with appropriate release name.<br />
<br />
<br />
git checkout production<br />
git tag -a WSXXX<br />
<br />
= Links =<br />
* [http://staging.wormbase.org staging site for testing]<br />
* [https://github.com/WormBase/website github repository]<br />
* [https://github.com/WormBase/website/issues github issue tracker]<br />
* [https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing workflow diagram]<br />
<br />
[[Category:Development General (Web Dev)]]<br />
[[Category:Getting Started (Web Dev)]]</div>Acabunochttps://wiki.wormbase.org/index.php?title=File:Git_Workflow_-_WormBase4.png&diff=24283File:Git Workflow - WormBase4.png2014-07-29T18:33:37Z<p>Acabunoc: Acabunoc uploaded a new version of &quot;File:Git Workflow - WormBase4.png&quot;</p>
<hr />
<div></div>Acabunochttps://wiki.wormbase.org/index.php?title=WebDev_2014.07.29-Agenda_and_Minutes&diff=24282WebDev 2014.07.29-Agenda and Minutes2014-07-29T14:33:38Z<p>Acabunoc: /* Minutes */</p>
<hr />
<div>= Agenda =<br />
<br />
== 1. Admin update ==<br />
<br />
== 2. Development status -- WS244 ==<br />
<br />
<br />
Pull Request Workflow:<br />
http://wiki.wormbase.org/index.php/Development_workflow_-_webdev<br />
<br />
== 3. Jbrowse update / discussion ==<br />
<br />
<br />
= Minutes =<br />
<br />
1. Admin update<br />
<br />
* middle of release<br />
* stable (WS243 - 100% uptime, 90 days)<br />
<br />
2. WS244<br />
<br />
* PR System working<br />
* Add meetings where we get together and go through all the PRs<br />
<br />
* Language options - bugs in GBrowse (browser dependant)<br />
<br />
* Pressing issue - expression data, data structure changed. Update for WS244.<br />
<br />
<br />
<br />
3. jBrowse<br />
<br />
<br />
* GBrowse - biographics w/ Lincoln<br />
** outstanding issue - group pattern, resulting image doesn't work<br />
** LS working on it. Fixed in the next few days<br />
<br />
* JBrowse<br />
** wanted to get all labels, descriptions and links fixed for core tracks<br />
** finished on Fri<br />
** tracks ready to be seen by people<br />
<br />
* Plan this week: <br />
# JBrowse supports includes like GBrowse<br />
#* clean up</div>Acabunochttps://wiki.wormbase.org/index.php?title=WebDev_2014.07.29-Agenda_and_Minutes&diff=24281WebDev 2014.07.29-Agenda and Minutes2014-07-29T14:01:08Z<p>Acabunoc: </p>
<hr />
<div>= Agenda =<br />
<br />
== 1. Admin update ==<br />
<br />
== 2. Development status -- WS244 ==<br />
<br />
<br />
Pull Request Workflow:<br />
http://wiki.wormbase.org/index.php/Development_workflow_-_webdev<br />
<br />
== 3. Jbrowse update / discussion ==<br />
<br />
<br />
= Minutes =<br />
<br />
1. Admin update<br />
<br />
2. WS244<br />
<br />
3. jBrowse</div>Acabunochttps://wiki.wormbase.org/index.php?title=WebDev_2014.07.29-Agenda_and_Minutes&diff=24280WebDev 2014.07.29-Agenda and Minutes2014-07-29T13:59:47Z<p>Acabunoc: /* 2. Development status -- WS244 */</p>
<hr />
<div>= Agenda =<br />
<br />
== 1. Admin update ==<br />
<br />
== 2. Development status -- WS244 ==<br />
<br />
<br />
Pull Request Workflow:<br />
http://wiki.wormbase.org/index.php/Development_workflow_-_webdev<br />
<br />
== 3. Jbrowse update / discussion ==</div>Acabunochttps://wiki.wormbase.org/index.php?title=Development_workflow_-_webdev&diff=24279Development workflow - webdev2014-07-29T13:55:12Z<p>Acabunoc: /* Testing & Code Review */</p>
<hr />
<div>This page describes the development model used by the web development team at WormBase using git as our version control system. This includes our branching strategy and release management. We use git and GitHub to help us manage development.<br />
<br />
= Overview Diagram =<br />
[[File:Git_Workflow_-_WormBase4.png]]<br />
<br />
[https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing Editable version of the diagram]<br />
<br />
= Contributing =<br />
<br />
Whenever you begin work on a new issue you should create a new branch for it. Any new major features should branch off <code>staging</code>. Once the feature is ready for testing, it can be merged back into <code>staging</code>. These aren't necessarily branches in the main repository - can be local, or on a developer's fork. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Branch_stratgey Read more on our branching strategy]<br />
<br />
git checkout -b myFeature staging<br />
<br />
Now you can make your changes, commit some code. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Commit_Messages Read more on commit messages]<br />
git add /PATH/TO/UPDATED/FILE<br />
git commit -m "Descriptive commit message"<br />
<br />
When you're ready, you can push your branch to GitHub<br />
<br />
git push origin myFeature<br />
<br />
Continue making changes until your code is ready for testing. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Is_my_code_ready_for_testing.3F Is my code ready for testing?]<br />
<br />
When your code is ready, go to GitHub and create a Pull Request. [http://nathanhoad.net/git-workflow-forks-remotes-and-pull-requests More info on Pull Requests.]<br />
<br />
# Go to the repository where you pushed your changes<br />
# Switch to your branch (myFeature)<br />
# Click the green '''Compare & review''' button<br />
# After reviewing all the changes, click on '''Create pull request''' in the header to send the pull request<br />
# In the description, write a short summary of the issues and changes made along with some links for testing<br />
<br />
Wait for another member of the web development team to review and merge your pull request. If more changes are requested, you can push more commits to the same branch and it will be added to the pull request.<br />
<br />
Once your pull request is merged, locally bring in the changes and delete your issue branch<br />
git checkout staging<br />
git pull<br />
git branch -d myFeature<br />
<br />
Go to the original github issue:<br />
# Add the '''Under testing''' label to your issue<br />
# Comment on the issue to notify all involved that it is ready for testing. Add links for testing for the ease of testers.<br />
# Another member of the WormBase group will close the issue once they have tested it<br />
<br />
== Is my code ready for testing? == <br />
<br />
* Have written tests demonstrating the problem in the issue<br />
* Fix the problem (ie pass the tests)<br />
* Complete the issue as much as possible without curators seeing an example<br />
* Code style meeting the [http://wiki.wormbase.org/index.php/Coding_standards WormBase standards] (indentation, comments, no debug statements)<br />
<br />
== Commit Messages ==<br />
git commit -m "COMMIT MESSAGE GOES HERE"<br />
<br />
Keep your commit message as descriptive as possible, reference any issues affected, close any this resolves:<br />
This is a summary of my commit.<br />
* here is a breakdown of the different changes<br />
* mention github users (@tharris) when appropriate<br />
* related to #YYY<br />
* fix #XXX<br />
<br />
Here is a template originally written by Tim Pope at tpope.net:<br />
<pre><br />
Short (50 chars or less) summary of changes<br />
<br />
More detailed explanatory text, if necessary. Wrap it to about 72<br />
characters or so. In some contexts, the first line is treated as the<br />
subject of an email and the rest of the text as the body. The blank<br />
line separating the summary from the body is critical (unless you omit<br />
the body entirely); tools like rebase can get confused if you run the<br />
two together.<br />
<br />
Further paragraphs come after blank lines.<br />
<br />
- Bullet points are okay, too<br />
<br />
- Typically a hyphen or asterisk is used for the bullet, preceded by a<br />
single space, with blank lines in between, but conventions vary here<br />
</pre><br />
<br />
= Testing & Code Review =<br />
There are two levels of review in our workflow.<br />
<br />
# Code review: At the pull request level, before code goes live on staging.wormbase.org<br />
# At the issue level, before closing an issue<br />
<br />
== Code Review: Pull Requests ==<br />
This level of testing is typically a code review before a Pull Request is merged into the staging branch. All members of the core development team are expected to keep an eye on the open Pull Requests and reviewing the ones they are most familiar with. Pull requests waiting for review should be left untouched for longer than two days after being assigned. <br />
<br />
* Test out the pull request (check out the branch)<br />
* Take a quick look at the code (are there comments? anything obvious missing)<br />
* Leave a comment on the PR if you notice anything that needs to be fixed<br />
* Merge the PR if you think it looks good<br />
<br />
== Testing: Issues ==<br />
All issues need to be tested and closed by at least one person who is not the developer who made the change. Ideally, it would be the curator asking for the feature/fix.<br />
<br />
'''If you would like to help test''':<br />
* Look at the [https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']. <br />
* All the changes for these issues are available for testing on [http://staging.wormbase.org staging.wormbase.org].<br />
* You can test out the changes and leave any feedback you have in the issue comments. <br />
* If you think this feature/fix is ready for production, you can '''remove the 'under testing' label''', or '''close the issue'''.<br />
<br />
= Branch Strategy =<br />
We use branches to help with our release management, testing strategy, and helping with parallel development among the team.<br />
<br />
== Main branches ==<br />
Inside the <code>WormBase/website</code> repository, there are three main branches: <code>master</code>, <code>staging</code> and <code>production</code>.<br />
<br />
* <code>master</code>: current, stable code. All new changes brought into master have been tested on [http://staging.wormbase.org staging.wormbase.org] and approved by either the curator requesting the change, or the development lead.<br />
<br />
* <code>staging</code>: any features/changes ready for testing should be pushed to the <code>staging</code> branch. This code gets pushed nightly to [http://staging.wormbase.org staging.wormbase.org].<br />
<br />
* <code>production</code>: the code currently in production. Branched off of <code>master</code> at each release.<br />
<br />
== Supporting branches == <br />
Other types of branches used can include feature branches and hotfixes. These branches are only intended to live until the new feature is merged into <code>staging</code> or the fix is completed.<br />
<br />
<br />
=== Feature branches ===<br />
Any new major features should branch off <code>staging</code>. Once the feature is ready for testing, it can be merged back into <code>staging</code>. These aren't necessarily branches in the main repository - can be local, or on a developer's fork.<br />
<br />
<br />
==== Testing issues ====<br />
All issues need to be tested and closed by at least one person who is not the developer who made the change. Ideally, it would be the curator asking for the feature/fix.<br />
<br />
'''If you would like to help test''':<br />
* Look at the [https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']. <br />
* All the changes for these issues are available for testing on [http://staging.wormbase.org staging.wormbase.org].<br />
<br />
'''If you are not the developer who pushed the code for this issue''':<br />
* You can test out the changes and leave any feedback you have in the issue comments. <br />
* If you think this feature/fix is ready for production, you can '''remove the 'under testing' label''', or '''close the issue'''.<br />
<br />
==== Moving a feature to <code>master</code> (pass testing) ====<br />
First, check to see which issues are currently being tested:<br />
[https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']<br />
<br />
If this list is '''empty''', <code>staging</code> can be merged onto the <code>master</code>.<br />
<br />
In github, create a [https://github.com/WormBase/website/pull/new/staging pull request for staging]. Look at the '''Commits''' and '''Files changes'''. In the comment, summary all the features/issues introduced and make sure they are stable. Click on '''send pull request'''.<br />
<br />
Once the pull request is reviewed, it can be merged into the master branch.<br />
<br />
=== Hotfixes ===<br />
If a major bugfix is needed in production, create a hotfix branch from production. When finished, the branch needs to be merged back into <code>production</code> and <code>staging</code><br />
<br />
==== Begining a fix ====<br />
git checkout -b hotfix-issXXX production<br />
<br />
Fix the bug and commit the fix in one or more commits. Reference the github issue:<br />
git commit -m "Severe production bug<br />
* search redirecting to home page<br />
* fix #XXX"<br />
<br />
==== Closing the fix ====<br />
The fix needs to be merged back to both <code>production</code> and <code>staging</code><br />
git checkout staging<br />
git merge hotfix-issXXX<br />
<br />
git checkout production<br />
git merge hotfix-issXXX<br />
<br />
<br />
= Development Timeline =<br />
<br />
See: [https://docs.google.com/document/d/1zIOm95tV9A14n9xnkPkMgiOTGcOIzx161y9UbDZvfW4/pub WormBase Release Workflow]<br />
<br />
= Release Management =<br />
When production is ready to updated for release WSXXX:<br />
<br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:master...staging pull request from staging to master]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:production...master pull request from master to production]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Tag production branch with appropriate release name.<br />
<br />
<br />
git checkout production<br />
git tag -a WSXXX<br />
<br />
= Links =<br />
* [http://staging.wormbase.org staging site for testing]<br />
* [https://github.com/WormBase/website github repository]<br />
* [https://github.com/WormBase/website/issues github issue tracker]<br />
* [https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing workflow diagram]<br />
<br />
[[Category:Development General (Web Dev)]]<br />
[[Category:Getting Started (Web Dev)]]</div>Acabunochttps://wiki.wormbase.org/index.php?title=Development_workflow_-_webdev&diff=24273Development workflow - webdev2014-07-25T21:08:13Z<p>Acabunoc: /* Testing & Code Review */</p>
<hr />
<div>This page describes the development model used by the web development team at WormBase using git as our version control system. This includes our branching strategy and release management. We use git and GitHub to help us manage development.<br />
<br />
= Overview Diagram =<br />
[[File:Git_Workflow_-_WormBase4.png]]<br />
<br />
[https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing Editable version of the diagram]<br />
<br />
= Contributing =<br />
<br />
Whenever you begin work on a new issue you should create a new branch for it. Any new major features should branch off <code>staging</code>. Once the feature is ready for testing, it can be merged back into <code>staging</code>. These aren't necessarily branches in the main repository - can be local, or on a developer's fork. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Branch_stratgey Read more on our branching strategy]<br />
<br />
git checkout -b myFeature staging<br />
<br />
Now you can make your changes, commit some code. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Commit_Messages Read more on commit messages]<br />
git add /PATH/TO/UPDATED/FILE<br />
git commit -m "Descriptive commit message"<br />
<br />
When you're ready, you can push your branch to GitHub<br />
<br />
git push origin myFeature<br />
<br />
Continue making changes until your code is ready for testing. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Is_my_code_ready_for_testing.3F Is my code ready for testing?]<br />
<br />
When your code is ready, go to GitHub and create a Pull Request. [http://nathanhoad.net/git-workflow-forks-remotes-and-pull-requests More info on Pull Requests.]<br />
<br />
# Go to the repository where you pushed your changes<br />
# Switch to your branch (myFeature)<br />
# Click the green '''Compare & review''' button<br />
# After reviewing all the changes, click on '''Create pull request''' in the header to send the pull request<br />
# In the description, write a short summary of the issues and changes made along with some links for testing<br />
<br />
Wait for another member of the web development team to review and merge your pull request. If more changes are requested, you can push more commits to the same branch and it will be added to the pull request.<br />
<br />
Once your pull request is merged, locally bring in the changes and delete your issue branch<br />
git checkout staging<br />
git pull<br />
git branch -d myFeature<br />
<br />
Go to the original github issue:<br />
# Add the '''Under testing''' label to your issue<br />
# Comment on the issue to notify all involved that it is ready for testing. Add links for testing for the ease of testers.<br />
# Another member of the WormBase group will close the issue once they have tested it<br />
<br />
== Is my code ready for testing? == <br />
<br />
* Have written tests demonstrating the problem in the issue<br />
* Fix the problem (ie pass the tests)<br />
* Complete the issue as much as possible without curators seeing an example<br />
* Code style meeting the [http://wiki.wormbase.org/index.php/Coding_standards WormBase standards] (indentation, comments, no debug statements)<br />
<br />
== Commit Messages ==<br />
git commit -m "COMMIT MESSAGE GOES HERE"<br />
<br />
Keep your commit message as descriptive as possible, reference any issues affected, close any this resolves:<br />
This is a summary of my commit.<br />
* here is a breakdown of the different changes<br />
* mention github users (@tharris) when appropriate<br />
* related to #YYY<br />
* fix #XXX<br />
<br />
Here is a template originally written by Tim Pope at tpope.net:<br />
<pre><br />
Short (50 chars or less) summary of changes<br />
<br />
More detailed explanatory text, if necessary. Wrap it to about 72<br />
characters or so. In some contexts, the first line is treated as the<br />
subject of an email and the rest of the text as the body. The blank<br />
line separating the summary from the body is critical (unless you omit<br />
the body entirely); tools like rebase can get confused if you run the<br />
two together.<br />
<br />
Further paragraphs come after blank lines.<br />
<br />
- Bullet points are okay, too<br />
<br />
- Typically a hyphen or asterisk is used for the bullet, preceded by a<br />
single space, with blank lines in between, but conventions vary here<br />
</pre><br />
<br />
= Testing & Code Review =<br />
There are two levels of review in our workflow.<br />
<br />
# Code review: At the pull request level, before code goes live on staging.wormbase.org<br />
# At the issue level, before closing an issue<br />
<br />
== Code Review: Pull Requests ==<br />
This level of testing is typically a code review before a Pull Request is merged into the staging branch. All members of the core development team are expected to keep an eye on the open Pull Requests and reviewing the ones they are most familiar with. Pull requests waiting for review should be left untouched for longer than two days after being assigned. <br />
<br />
<br />
== Testing: Issues ==<br />
All issues need to be tested and closed by at least one person who is not the developer who made the change. Ideally, it would be the curator asking for the feature/fix.<br />
<br />
'''If you would like to help test''':<br />
* Look at the [https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']. <br />
* All the changes for these issues are available for testing on [http://staging.wormbase.org staging.wormbase.org].<br />
* You can test out the changes and leave any feedback you have in the issue comments. <br />
* If you think this feature/fix is ready for production, you can '''remove the 'under testing' label''', or '''close the issue'''.<br />
<br />
= Branch Strategy =<br />
We use branches to help with our release management, testing strategy, and helping with parallel development among the team.<br />
<br />
== Main branches ==<br />
Inside the <code>WormBase/website</code> repository, there are three main branches: <code>master</code>, <code>staging</code> and <code>production</code>.<br />
<br />
* <code>master</code>: current, stable code. All new changes brought into master have been tested on [http://staging.wormbase.org staging.wormbase.org] and approved by either the curator requesting the change, or the development lead.<br />
<br />
* <code>staging</code>: any features/changes ready for testing should be pushed to the <code>staging</code> branch. This code gets pushed nightly to [http://staging.wormbase.org staging.wormbase.org].<br />
<br />
* <code>production</code>: the code currently in production. Branched off of <code>master</code> at each release.<br />
<br />
== Supporting branches == <br />
Other types of branches used can include feature branches and hotfixes. These branches are only intended to live until the new feature is merged into <code>staging</code> or the fix is completed.<br />
<br />
<br />
=== Feature branches ===<br />
Any new major features should branch off <code>staging</code>. Once the feature is ready for testing, it can be merged back into <code>staging</code>. These aren't necessarily branches in the main repository - can be local, or on a developer's fork.<br />
<br />
<br />
==== Testing issues ====<br />
All issues need to be tested and closed by at least one person who is not the developer who made the change. Ideally, it would be the curator asking for the feature/fix.<br />
<br />
'''If you would like to help test''':<br />
* Look at the [https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']. <br />
* All the changes for these issues are available for testing on [http://staging.wormbase.org staging.wormbase.org].<br />
<br />
'''If you are not the developer who pushed the code for this issue''':<br />
* You can test out the changes and leave any feedback you have in the issue comments. <br />
* If you think this feature/fix is ready for production, you can '''remove the 'under testing' label''', or '''close the issue'''.<br />
<br />
==== Moving a feature to <code>master</code> (pass testing) ====<br />
First, check to see which issues are currently being tested:<br />
[https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']<br />
<br />
If this list is '''empty''', <code>staging</code> can be merged onto the <code>master</code>.<br />
<br />
In github, create a [https://github.com/WormBase/website/pull/new/staging pull request for staging]. Look at the '''Commits''' and '''Files changes'''. In the comment, summary all the features/issues introduced and make sure they are stable. Click on '''send pull request'''.<br />
<br />
Once the pull request is reviewed, it can be merged into the master branch.<br />
<br />
=== Hotfixes ===<br />
If a major bugfix is needed in production, create a hotfix branch from production. When finished, the branch needs to be merged back into <code>production</code> and <code>staging</code><br />
<br />
==== Begining a fix ====<br />
git checkout -b hotfix-issXXX production<br />
<br />
Fix the bug and commit the fix in one or more commits. Reference the github issue:<br />
git commit -m "Severe production bug<br />
* search redirecting to home page<br />
* fix #XXX"<br />
<br />
==== Closing the fix ====<br />
The fix needs to be merged back to both <code>production</code> and <code>staging</code><br />
git checkout staging<br />
git merge hotfix-issXXX<br />
<br />
git checkout production<br />
git merge hotfix-issXXX<br />
<br />
<br />
= Development Timeline =<br />
<br />
See: [https://docs.google.com/document/d/1zIOm95tV9A14n9xnkPkMgiOTGcOIzx161y9UbDZvfW4/pub WormBase Release Workflow]<br />
<br />
= Release Management =<br />
When production is ready to updated for release WSXXX:<br />
<br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:master...staging pull request from staging to master]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:production...master pull request from master to production]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Tag production branch with appropriate release name.<br />
<br />
<br />
git checkout production<br />
git tag -a WSXXX<br />
<br />
= Links =<br />
* [http://staging.wormbase.org staging site for testing]<br />
* [https://github.com/WormBase/website github repository]<br />
* [https://github.com/WormBase/website/issues github issue tracker]<br />
* [https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing workflow diagram]<br />
<br />
[[Category:Development General (Web Dev)]]<br />
[[Category:Getting Started (Web Dev)]]</div>Acabunochttps://wiki.wormbase.org/index.php?title=Development_workflow_-_webdev&diff=24272Development workflow - webdev2014-07-25T21:07:46Z<p>Acabunoc: /* Testing / Code Review */</p>
<hr />
<div>This page describes the development model used by the web development team at WormBase using git as our version control system. This includes our branching strategy and release management. We use git and GitHub to help us manage development.<br />
<br />
= Overview Diagram =<br />
[[File:Git_Workflow_-_WormBase4.png]]<br />
<br />
[https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing Editable version of the diagram]<br />
<br />
= Contributing =<br />
<br />
Whenever you begin work on a new issue you should create a new branch for it. Any new major features should branch off <code>staging</code>. Once the feature is ready for testing, it can be merged back into <code>staging</code>. These aren't necessarily branches in the main repository - can be local, or on a developer's fork. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Branch_stratgey Read more on our branching strategy]<br />
<br />
git checkout -b myFeature staging<br />
<br />
Now you can make your changes, commit some code. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Commit_Messages Read more on commit messages]<br />
git add /PATH/TO/UPDATED/FILE<br />
git commit -m "Descriptive commit message"<br />
<br />
When you're ready, you can push your branch to GitHub<br />
<br />
git push origin myFeature<br />
<br />
Continue making changes until your code is ready for testing. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Is_my_code_ready_for_testing.3F Is my code ready for testing?]<br />
<br />
When your code is ready, go to GitHub and create a Pull Request. [http://nathanhoad.net/git-workflow-forks-remotes-and-pull-requests More info on Pull Requests.]<br />
<br />
# Go to the repository where you pushed your changes<br />
# Switch to your branch (myFeature)<br />
# Click the green '''Compare & review''' button<br />
# After reviewing all the changes, click on '''Create pull request''' in the header to send the pull request<br />
# In the description, write a short summary of the issues and changes made along with some links for testing<br />
<br />
Wait for another member of the web development team to review and merge your pull request. If more changes are requested, you can push more commits to the same branch and it will be added to the pull request.<br />
<br />
Once your pull request is merged, locally bring in the changes and delete your issue branch<br />
git checkout staging<br />
git pull<br />
git branch -d myFeature<br />
<br />
Go to the original github issue:<br />
# Add the '''Under testing''' label to your issue<br />
# Comment on the issue to notify all involved that it is ready for testing. Add links for testing for the ease of testers.<br />
# Another member of the WormBase group will close the issue once they have tested it<br />
<br />
== Is my code ready for testing? == <br />
<br />
* Have written tests demonstrating the problem in the issue<br />
* Fix the problem (ie pass the tests)<br />
* Complete the issue as much as possible without curators seeing an example<br />
* Code style meeting the [http://wiki.wormbase.org/index.php/Coding_standards WormBase standards] (indentation, comments, no debug statements)<br />
<br />
== Commit Messages ==<br />
git commit -m "COMMIT MESSAGE GOES HERE"<br />
<br />
Keep your commit message as descriptive as possible, reference any issues affected, close any this resolves:<br />
This is a summary of my commit.<br />
* here is a breakdown of the different changes<br />
* mention github users (@tharris) when appropriate<br />
* related to #YYY<br />
* fix #XXX<br />
<br />
Here is a template originally written by Tim Pope at tpope.net:<br />
<pre><br />
Short (50 chars or less) summary of changes<br />
<br />
More detailed explanatory text, if necessary. Wrap it to about 72<br />
characters or so. In some contexts, the first line is treated as the<br />
subject of an email and the rest of the text as the body. The blank<br />
line separating the summary from the body is critical (unless you omit<br />
the body entirely); tools like rebase can get confused if you run the<br />
two together.<br />
<br />
Further paragraphs come after blank lines.<br />
<br />
- Bullet points are okay, too<br />
<br />
- Typically a hyphen or asterisk is used for the bullet, preceded by a<br />
single space, with blank lines in between, but conventions vary here<br />
</pre><br />
<br />
= Testing & Code Review =<br />
There are two levels of review in our workflow.<br />
<br />
# Code review: At the pull request level, before code goes live on staging.wormbase.org<br />
# At the issue level, before closing an issue<br />
<br />
== Pull Requests ==<br />
This level of testing is typically a code review before a Pull Request is merged into the staging branch. All members of the core development team are expected to keep an eye on the open Pull Requests and reviewing the ones they are most familiar with. Pull requests waiting for review should be left untouched for longer than two days after being assigned. <br />
<br />
<br />
<br />
== Issues ==<br />
All issues need to be tested and closed by at least one person who is not the developer who made the change. Ideally, it would be the curator asking for the feature/fix.<br />
<br />
'''If you would like to help test''':<br />
* Look at the [https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']. <br />
* All the changes for these issues are available for testing on [http://staging.wormbase.org staging.wormbase.org].<br />
* You can test out the changes and leave any feedback you have in the issue comments. <br />
* If you think this feature/fix is ready for production, you can '''remove the 'under testing' label''', or '''close the issue'''.<br />
<br />
= Branch Strategy =<br />
We use branches to help with our release management, testing strategy, and helping with parallel development among the team.<br />
<br />
== Main branches ==<br />
Inside the <code>WormBase/website</code> repository, there are three main branches: <code>master</code>, <code>staging</code> and <code>production</code>.<br />
<br />
* <code>master</code>: current, stable code. All new changes brought into master have been tested on [http://staging.wormbase.org staging.wormbase.org] and approved by either the curator requesting the change, or the development lead.<br />
<br />
* <code>staging</code>: any features/changes ready for testing should be pushed to the <code>staging</code> branch. This code gets pushed nightly to [http://staging.wormbase.org staging.wormbase.org].<br />
<br />
* <code>production</code>: the code currently in production. Branched off of <code>master</code> at each release.<br />
<br />
== Supporting branches == <br />
Other types of branches used can include feature branches and hotfixes. These branches are only intended to live until the new feature is merged into <code>staging</code> or the fix is completed.<br />
<br />
<br />
=== Feature branches ===<br />
Any new major features should branch off <code>staging</code>. Once the feature is ready for testing, it can be merged back into <code>staging</code>. These aren't necessarily branches in the main repository - can be local, or on a developer's fork.<br />
<br />
<br />
==== Testing issues ====<br />
All issues need to be tested and closed by at least one person who is not the developer who made the change. Ideally, it would be the curator asking for the feature/fix.<br />
<br />
'''If you would like to help test''':<br />
* Look at the [https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']. <br />
* All the changes for these issues are available for testing on [http://staging.wormbase.org staging.wormbase.org].<br />
<br />
'''If you are not the developer who pushed the code for this issue''':<br />
* You can test out the changes and leave any feedback you have in the issue comments. <br />
* If you think this feature/fix is ready for production, you can '''remove the 'under testing' label''', or '''close the issue'''.<br />
<br />
==== Moving a feature to <code>master</code> (pass testing) ====<br />
First, check to see which issues are currently being tested:<br />
[https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']<br />
<br />
If this list is '''empty''', <code>staging</code> can be merged onto the <code>master</code>.<br />
<br />
In github, create a [https://github.com/WormBase/website/pull/new/staging pull request for staging]. Look at the '''Commits''' and '''Files changes'''. In the comment, summary all the features/issues introduced and make sure they are stable. Click on '''send pull request'''.<br />
<br />
Once the pull request is reviewed, it can be merged into the master branch.<br />
<br />
=== Hotfixes ===<br />
If a major bugfix is needed in production, create a hotfix branch from production. When finished, the branch needs to be merged back into <code>production</code> and <code>staging</code><br />
<br />
==== Begining a fix ====<br />
git checkout -b hotfix-issXXX production<br />
<br />
Fix the bug and commit the fix in one or more commits. Reference the github issue:<br />
git commit -m "Severe production bug<br />
* search redirecting to home page<br />
* fix #XXX"<br />
<br />
==== Closing the fix ====<br />
The fix needs to be merged back to both <code>production</code> and <code>staging</code><br />
git checkout staging<br />
git merge hotfix-issXXX<br />
<br />
git checkout production<br />
git merge hotfix-issXXX<br />
<br />
<br />
= Development Timeline =<br />
<br />
See: [https://docs.google.com/document/d/1zIOm95tV9A14n9xnkPkMgiOTGcOIzx161y9UbDZvfW4/pub WormBase Release Workflow]<br />
<br />
= Release Management =<br />
When production is ready to updated for release WSXXX:<br />
<br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:master...staging pull request from staging to master]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:production...master pull request from master to production]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Tag production branch with appropriate release name.<br />
<br />
<br />
git checkout production<br />
git tag -a WSXXX<br />
<br />
= Links =<br />
* [http://staging.wormbase.org staging site for testing]<br />
* [https://github.com/WormBase/website github repository]<br />
* [https://github.com/WormBase/website/issues github issue tracker]<br />
* [https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing workflow diagram]<br />
<br />
[[Category:Development General (Web Dev)]]<br />
[[Category:Getting Started (Web Dev)]]</div>Acabunochttps://wiki.wormbase.org/index.php?title=Development_workflow_-_webdev&diff=24271Development workflow - webdev2014-07-25T20:54:54Z<p>Acabunoc: </p>
<hr />
<div>This page describes the development model used by the web development team at WormBase using git as our version control system. This includes our branching strategy and release management. We use git and GitHub to help us manage development.<br />
<br />
= Overview Diagram =<br />
[[File:Git_Workflow_-_WormBase4.png]]<br />
<br />
[https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing Editable version of the diagram]<br />
<br />
= Contributing =<br />
<br />
Whenever you begin work on a new issue you should create a new branch for it. Any new major features should branch off <code>staging</code>. Once the feature is ready for testing, it can be merged back into <code>staging</code>. These aren't necessarily branches in the main repository - can be local, or on a developer's fork. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Branch_stratgey Read more on our branching strategy]<br />
<br />
git checkout -b myFeature staging<br />
<br />
Now you can make your changes, commit some code. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Commit_Messages Read more on commit messages]<br />
git add /PATH/TO/UPDATED/FILE<br />
git commit -m "Descriptive commit message"<br />
<br />
When you're ready, you can push your branch to GitHub<br />
<br />
git push origin myFeature<br />
<br />
Continue making changes until your code is ready for testing. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Is_my_code_ready_for_testing.3F Is my code ready for testing?]<br />
<br />
When your code is ready, go to GitHub and create a Pull Request. [http://nathanhoad.net/git-workflow-forks-remotes-and-pull-requests More info on Pull Requests.]<br />
<br />
# Go to the repository where you pushed your changes<br />
# Switch to your branch (myFeature)<br />
# Click the green '''Compare & review''' button<br />
# After reviewing all the changes, click on '''Create pull request''' in the header to send the pull request<br />
# In the description, write a short summary of the issues and changes made along with some links for testing<br />
<br />
Wait for another member of the web development team to review and merge your pull request. If more changes are requested, you can push more commits to the same branch and it will be added to the pull request.<br />
<br />
Once your pull request is merged, locally bring in the changes and delete your issue branch<br />
git checkout staging<br />
git pull<br />
git branch -d myFeature<br />
<br />
Go to the original github issue:<br />
# Add the '''Under testing''' label to your issue<br />
# Comment on the issue to notify all involved that it is ready for testing. Add links for testing for the ease of testers.<br />
# Another member of the WormBase group will close the issue once they have tested it<br />
<br />
== Is my code ready for testing? == <br />
<br />
* Have written tests demonstrating the problem in the issue<br />
* Fix the problem (ie pass the tests)<br />
* Complete the issue as much as possible without curators seeing an example<br />
* Code style meeting the [http://wiki.wormbase.org/index.php/Coding_standards WormBase standards] (indentation, comments, no debug statements)<br />
<br />
== Commit Messages ==<br />
git commit -m "COMMIT MESSAGE GOES HERE"<br />
<br />
Keep your commit message as descriptive as possible, reference any issues affected, close any this resolves:<br />
This is a summary of my commit.<br />
* here is a breakdown of the different changes<br />
* mention github users (@tharris) when appropriate<br />
* related to #YYY<br />
* fix #XXX<br />
<br />
Here is a template originally written by Tim Pope at tpope.net:<br />
<pre><br />
Short (50 chars or less) summary of changes<br />
<br />
More detailed explanatory text, if necessary. Wrap it to about 72<br />
characters or so. In some contexts, the first line is treated as the<br />
subject of an email and the rest of the text as the body. The blank<br />
line separating the summary from the body is critical (unless you omit<br />
the body entirely); tools like rebase can get confused if you run the<br />
two together.<br />
<br />
Further paragraphs come after blank lines.<br />
<br />
- Bullet points are okay, too<br />
<br />
- Typically a hyphen or asterisk is used for the bullet, preceded by a<br />
single space, with blank lines in between, but conventions vary here<br />
</pre><br />
<br />
= Testing / Code Review =<br />
There are two levels of testing/review in our workflow.<br />
<br />
# At the pull request level, before code goes live on staging.wormbase.org<br />
# At the issue level, before closing an issue<br />
<br />
== Pull Requests ==<br />
This level of testing is typically a code review before a Pull Request is merged into the staging branch. All members of the core development team are expected to keep an eye on the open Pull Requests and reviewing the ones they are most familiar with. Pull requests waiting for review should be left untouched for longer than two days after being assigned. <br />
<br />
<br />
<br />
== Issues ==<br />
All issues need to be tested and closed by at least one person who is not the developer who made the change. Ideally, it would be the curator asking for the feature/fix.<br />
<br />
'''If you would like to help test''':<br />
* Look at the [https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']. <br />
* All the changes for these issues are available for testing on [http://staging.wormbase.org staging.wormbase.org].<br />
<br />
'''If you are not the developer who pushed the code for this issue''':<br />
* You can test out the changes and leave any feedback you have in the issue comments. <br />
* If you think this feature/fix is ready for production, you can '''remove the 'under testing' label''', or '''close the issue'''.<br />
<br />
<br />
<br />
= Branch Strategy =<br />
We use branches to help with our release management, testing strategy, and helping with parallel development among the team.<br />
<br />
== Main branches ==<br />
Inside the <code>WormBase/website</code> repository, there are three main branches: <code>master</code>, <code>staging</code> and <code>production</code>.<br />
<br />
* <code>master</code>: current, stable code. All new changes brought into master have been tested on [http://staging.wormbase.org staging.wormbase.org] and approved by either the curator requesting the change, or the development lead.<br />
<br />
* <code>staging</code>: any features/changes ready for testing should be pushed to the <code>staging</code> branch. This code gets pushed nightly to [http://staging.wormbase.org staging.wormbase.org].<br />
<br />
* <code>production</code>: the code currently in production. Branched off of <code>master</code> at each release.<br />
<br />
== Supporting branches == <br />
Other types of branches used can include feature branches and hotfixes. These branches are only intended to live until the new feature is merged into <code>staging</code> or the fix is completed.<br />
<br />
<br />
=== Feature branches ===<br />
Any new major features should branch off <code>staging</code>. Once the feature is ready for testing, it can be merged back into <code>staging</code>. These aren't necessarily branches in the main repository - can be local, or on a developer's fork.<br />
<br />
<br />
==== Testing issues ====<br />
All issues need to be tested and closed by at least one person who is not the developer who made the change. Ideally, it would be the curator asking for the feature/fix.<br />
<br />
'''If you would like to help test''':<br />
* Look at the [https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']. <br />
* All the changes for these issues are available for testing on [http://staging.wormbase.org staging.wormbase.org].<br />
<br />
'''If you are not the developer who pushed the code for this issue''':<br />
* You can test out the changes and leave any feedback you have in the issue comments. <br />
* If you think this feature/fix is ready for production, you can '''remove the 'under testing' label''', or '''close the issue'''.<br />
<br />
==== Moving a feature to <code>master</code> (pass testing) ====<br />
First, check to see which issues are currently being tested:<br />
[https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']<br />
<br />
If this list is '''empty''', <code>staging</code> can be merged onto the <code>master</code>.<br />
<br />
In github, create a [https://github.com/WormBase/website/pull/new/staging pull request for staging]. Look at the '''Commits''' and '''Files changes'''. In the comment, summary all the features/issues introduced and make sure they are stable. Click on '''send pull request'''.<br />
<br />
Once the pull request is reviewed, it can be merged into the master branch.<br />
<br />
=== Hotfixes ===<br />
If a major bugfix is needed in production, create a hotfix branch from production. When finished, the branch needs to be merged back into <code>production</code> and <code>staging</code><br />
<br />
==== Begining a fix ====<br />
git checkout -b hotfix-issXXX production<br />
<br />
Fix the bug and commit the fix in one or more commits. Reference the github issue:<br />
git commit -m "Severe production bug<br />
* search redirecting to home page<br />
* fix #XXX"<br />
<br />
==== Closing the fix ====<br />
The fix needs to be merged back to both <code>production</code> and <code>staging</code><br />
git checkout staging<br />
git merge hotfix-issXXX<br />
<br />
git checkout production<br />
git merge hotfix-issXXX<br />
<br />
<br />
= Development Timeline =<br />
<br />
See: [https://docs.google.com/document/d/1zIOm95tV9A14n9xnkPkMgiOTGcOIzx161y9UbDZvfW4/pub WormBase Release Workflow]<br />
<br />
= Release Management =<br />
When production is ready to updated for release WSXXX:<br />
<br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:master...staging pull request from staging to master]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:production...master pull request from master to production]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Tag production branch with appropriate release name.<br />
<br />
<br />
git checkout production<br />
git tag -a WSXXX<br />
<br />
= Links =<br />
* [http://staging.wormbase.org staging site for testing]<br />
* [https://github.com/WormBase/website github repository]<br />
* [https://github.com/WormBase/website/issues github issue tracker]<br />
* [https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing workflow diagram]<br />
<br />
[[Category:Development General (Web Dev)]]<br />
[[Category:Getting Started (Web Dev)]]</div>Acabunochttps://wiki.wormbase.org/index.php?title=Development_workflow_-_webdev&diff=24270Development workflow - webdev2014-07-25T20:09:56Z<p>Acabunoc: /* Contributing */</p>
<hr />
<div>This page describes the development model used by the web development team at WormBase using git as our version control system. This includes our branching strategy and release management. We use git and GitHub to help us manage development.<br />
<br />
= Overview Diagram =<br />
[[File:Git_Workflow_-_WormBase4.png]]<br />
<br />
[https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing Editable version of the diagram]<br />
<br />
= Contributing =<br />
<br />
Whenever you begin work on a new issue you should create a new branch for it. Any new major features should branch off <code>staging</code>. Once the feature is ready for testing, it can be merged back into <code>staging</code>. These aren't necessarily branches in the main repository - can be local, or on a developer's fork. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Branch_stratgey Read more on our branching strategy]<br />
<br />
git checkout -b myFeature staging<br />
<br />
Now you can make your changes, commit some code. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Commit_Messages Read more on commit messages]<br />
git add /PATH/TO/UPDATED/FILE<br />
git commit -m "Descriptive commit message"<br />
<br />
When you're ready, you can push your branch to GitHub<br />
<br />
git push origin myFeature<br />
<br />
Continue making changes until your code is ready for testing. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Is_my_code_ready_for_testing.3F Is my code ready for testing?]<br />
<br />
When your code is ready, go to GitHub and create a Pull Request. [http://nathanhoad.net/git-workflow-forks-remotes-and-pull-requests More info on Pull Requests.]<br />
<br />
# Go to the repository where you pushed your changes<br />
# Switch to your branch (myFeature)<br />
# Click the green '''Compare & review''' button<br />
# After reviewing all the changes, click on '''Create pull request''' in the header to send the pull request<br />
# In the description, write a short summary of the issues and changes made along with some links for testing<br />
<br />
Wait for another member of the web development team to review and merge your pull request. If more changes are requested, you can push more commits to the same branch and it will be added to the pull request.<br />
<br />
Once your pull request is merged, locally bring in the changes and delete your issue branch<br />
git checkout staging<br />
git pull<br />
git branch -d myFeature<br />
<br />
Go to the original github issue:<br />
# Add the '''Under testing''' label to your issue<br />
# Comment on the issue to notify all involved that it is ready for testing. Add links for testing for the ease of testers.<br />
# Another member of the WormBase group will close the issue once they have tested it<br />
<br />
== Is my code ready for testing? == <br />
<br />
* Have written tests demonstrating the problem in the issue<br />
* Fix the problem (ie pass the tests)<br />
* Complete the issue as much as possible without curators seeing an example<br />
* Code style meeting the [http://wiki.wormbase.org/index.php/Coding_standards WormBase standards] (indentation, comments, no debug statements)<br />
<br />
== Commit Messages ==<br />
git commit -m "COMMIT MESSAGE GOES HERE"<br />
<br />
Keep your commit message as descriptive as possible, reference any issues affected, close any this resolves:<br />
This is a summary of my commit.<br />
* here is a breakdown of the different changes<br />
* mention github users (@tharris) when appropriate<br />
* related to #YYY<br />
* fix #XXX<br />
<br />
Here is a template originally written by Tim Pope at tpope.net:<br />
<pre><br />
Short (50 chars or less) summary of changes<br />
<br />
More detailed explanatory text, if necessary. Wrap it to about 72<br />
characters or so. In some contexts, the first line is treated as the<br />
subject of an email and the rest of the text as the body. The blank<br />
line separating the summary from the body is critical (unless you omit<br />
the body entirely); tools like rebase can get confused if you run the<br />
two together.<br />
<br />
Further paragraphs come after blank lines.<br />
<br />
- Bullet points are okay, too<br />
<br />
- Typically a hyphen or asterisk is used for the bullet, preceded by a<br />
single space, with blank lines in between, but conventions vary here<br />
</pre><br />
<br />
= Testing =<br />
All members of the core development team are expected to keep an eye on the current Pull Requests.<br />
<br />
= Branch Strategy =<br />
We use branches to help with our release management, testing strategy, and helping with parallel development among the team.<br />
<br />
== Main branches ==<br />
Inside the <code>WormBase/website</code> repository, there are three main branches: <code>master</code>, <code>staging</code> and <code>production</code>.<br />
<br />
* <code>master</code>: current, stable code. All new changes brought into master have been tested on [http://staging.wormbase.org staging.wormbase.org] and approved by either the curator requesting the change, or the development lead.<br />
<br />
* <code>staging</code>: any features/changes ready for testing should be pushed to the <code>staging</code> branch. This code gets pushed nightly to [http://staging.wormbase.org staging.wormbase.org].<br />
<br />
* <code>production</code>: the code currently in production. Branched off of <code>master</code> at each release.<br />
<br />
== Supporting branches == <br />
Other types of branches used can include feature branches and hotfixes. These branches are only intended to live until the new feature is merged into <code>staging</code> or the fix is completed.<br />
<br />
<br />
=== Feature branches ===<br />
Any new major features should branch off <code>staging</code>. Once the feature is ready for testing, it can be merged back into <code>staging</code>. These aren't necessarily branches in the main repository - can be local, or on a developer's fork.<br />
<br />
<br />
==== Testing issues ====<br />
All issues need to be tested and closed by at least one person who is not the developer who made the change. Ideally, it would be the curator asking for the feature/fix.<br />
<br />
'''If you would like to help test''':<br />
* Look at the [https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']. <br />
* All the changes for these issues are available for testing on [http://staging.wormbase.org staging.wormbase.org].<br />
<br />
'''If you are not the developer who pushed the code for this issue''':<br />
* You can test out the changes and leave any feedback you have in the issue comments. <br />
* If you think this feature/fix is ready for production, you can '''remove the 'under testing' label''', or '''close the issue'''.<br />
<br />
==== Moving a feature to <code>master</code> (pass testing) ====<br />
First, check to see which issues are currently being tested:<br />
[https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']<br />
<br />
If this list is '''empty''', <code>staging</code> can be merged onto the <code>master</code>.<br />
<br />
In github, create a [https://github.com/WormBase/website/pull/new/staging pull request for staging]. Look at the '''Commits''' and '''Files changes'''. In the comment, summary all the features/issues introduced and make sure they are stable. Click on '''send pull request'''.<br />
<br />
Once the pull request is reviewed, it can be merged into the master branch.<br />
<br />
=== Hotfixes ===<br />
If a major bugfix is needed in production, create a hotfix branch from production. When finished, the branch needs to be merged back into <code>production</code> and <code>staging</code><br />
<br />
==== Begining a fix ====<br />
git checkout -b hotfix-issXXX production<br />
<br />
Fix the bug and commit the fix in one or more commits. Reference the github issue:<br />
git commit -m "Severe production bug<br />
* search redirecting to home page<br />
* fix #XXX"<br />
<br />
==== Closing the fix ====<br />
The fix needs to be merged back to both <code>production</code> and <code>staging</code><br />
git checkout staging<br />
git merge hotfix-issXXX<br />
<br />
git checkout production<br />
git merge hotfix-issXXX<br />
<br />
<br />
= Development Timeline =<br />
<br />
See: [https://docs.google.com/document/d/1zIOm95tV9A14n9xnkPkMgiOTGcOIzx161y9UbDZvfW4/pub WormBase Release Workflow]<br />
<br />
= Release Management =<br />
When production is ready to updated for release WSXXX:<br />
<br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:master...staging pull request from staging to master]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:production...master pull request from master to production]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Tag production branch with appropriate release name.<br />
<br />
<br />
git checkout production<br />
git tag -a WSXXX<br />
<br />
= Links =<br />
* [http://staging.wormbase.org staging site for testing]<br />
* [https://github.com/WormBase/website github repository]<br />
* [https://github.com/WormBase/website/issues github issue tracker]<br />
* [https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing workflow diagram]<br />
<br />
[[Category:Development General (Web Dev)]]<br />
[[Category:Getting Started (Web Dev)]]</div>Acabunochttps://wiki.wormbase.org/index.php?title=Development_workflow_-_webdev&diff=24269Development workflow - webdev2014-07-25T20:09:48Z<p>Acabunoc: /* Contributing */</p>
<hr />
<div>This page describes the development model used by the web development team at WormBase using git as our version control system. This includes our branching strategy and release management. We use git and GitHub to help us manage development.<br />
<br />
= Overview Diagram =<br />
[[File:Git_Workflow_-_WormBase4.png]]<br />
<br />
[https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing Editable version of the diagram]<br />
<br />
= Contributing =<br />
<br />
Whenever you begin work on a new issue you should create a new branch for it. Any new major features should branch off <code>staging</code>. Once the feature is ready for testing, it can be merged back into <code>staging</code>. These aren't necessarily branches in the main repository - can be local, or on a developer's fork. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Branch_stratgey Read more on our branching strategy]<br />
<br />
git checkout -b myFeature staging<br />
<br />
Now you can make your changes, commit some code. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Commit_Messages Read more on commit messages]<br />
git add /PATH/TO/UPDATED/FILE<br />
git commit -m "Descriptive commit message"<br />
<br />
When you're ready, you can push your branch to GitHub<br />
<br />
git push origin myFeature<br />
<br />
Continue making changes until your code is ready for testing. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Is_my_code_ready_for_testing.3F Is my code ready for testing?]<br />
<br />
When your code is ready, go to GitHub and create a Pull Request. [http://nathanhoad.net/git-workflow-forks-remotes-and-pull-requests More info on Pull Requests.]<br />
<br />
# Go to the repository where you pushed your changes<br />
# Switch to your branch (myFeature)<br />
# Click the green '''Compare & review''' button<br />
# After reviewing all the changes, click on '''Create pull request''' in the header to send the pull request<br />
# In the description, write a short summary of the issues and changes made along with some links for testing<br />
<br />
Wait for another member of the web development team to review and merge your pull request. If more changes are requested, you can push more commits to the same branch and it will be added to the pull request.<br />
<br />
Once your pull request is merged, locally bring in the changes and delete your issue branch<br />
git checkout staging<br />
git pull<br />
git branch -d myFeature<br />
<br />
Go to the original github issue:<br />
# Add the '''Under testing''' label to your issue<br />
# Comment on the issue to notify all involved that it is ready for testing. Add links for testing for the ease of testers.<br />
# Another member of the WormBase group will close the issue once they have tested it<br />
<br />
== Is my code ready for testing? == <br />
<br />
* Have written tests demonstrating the problem in the issue<br />
* Fix the problem (ie pass the tests)<br />
* Complete the issue as much as possible without curators seeing an example<br />
* Code style meeting the [http://wiki.wormbase.org/index.php/Coding_standards WormBase standards] (indentation, comments, no debug statements)<br />
<br />
== Commit Messages ==<br />
git commit -m "COMMIT MESSAGE GOES HERE"<br />
<br />
Keep your commit message as descriptive as possible, reference any issues affected, close any this resolves:<br />
This is a summary of my commit.<br />
* here is a breakdown of the different changes<br />
* mention github users (@tharris) when appropriate<br />
* related to #YYY<br />
* fix #XXX<br />
<br />
Here is a template originally written by Tim Pope at tpope.net:<br />
<pre><br />
Short (50 chars or less) summary of changes<br />
<br />
More detailed explanatory text, if necessary. Wrap it to about 72<br />
characters or so. In some contexts, the first line is treated as the<br />
subject of an email and the rest of the text as the body. The blank<br />
line separating the summary from the body is critical (unless you omit<br />
the body entirely); tools like rebase can get confused if you run the<br />
two together.<br />
<br />
Further paragraphs come after blank lines.<br />
<br />
- Bullet points are okay, too<br />
<br />
- Typically a hyphen or asterisk is used for the bullet, preceded by a<br />
single space, with blank lines in between, but conventions vary here<br />
</pre><br />
<br />
= Testing =<br />
All members of the core development team are expected to keep an eye on the current Pull Requests.<br />
<br />
= Branch Strategy =<br />
We use branches to help with our release management, testing strategy, and helping with parallel development among the team.<br />
<br />
== Main branches ==<br />
Inside the <code>WormBase/website</code> repository, there are three main branches: <code>master</code>, <code>staging</code> and <code>production</code>.<br />
<br />
* <code>master</code>: current, stable code. All new changes brought into master have been tested on [http://staging.wormbase.org staging.wormbase.org] and approved by either the curator requesting the change, or the development lead.<br />
<br />
* <code>staging</code>: any features/changes ready for testing should be pushed to the <code>staging</code> branch. This code gets pushed nightly to [http://staging.wormbase.org staging.wormbase.org].<br />
<br />
* <code>production</code>: the code currently in production. Branched off of <code>master</code> at each release.<br />
<br />
== Supporting branches == <br />
Other types of branches used can include feature branches and hotfixes. These branches are only intended to live until the new feature is merged into <code>staging</code> or the fix is completed.<br />
<br />
<br />
=== Feature branches ===<br />
Any new major features should branch off <code>staging</code>. Once the feature is ready for testing, it can be merged back into <code>staging</code>. These aren't necessarily branches in the main repository - can be local, or on a developer's fork.<br />
<br />
<br />
==== Testing issues ====<br />
All issues need to be tested and closed by at least one person who is not the developer who made the change. Ideally, it would be the curator asking for the feature/fix.<br />
<br />
'''If you would like to help test''':<br />
* Look at the [https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']. <br />
* All the changes for these issues are available for testing on [http://staging.wormbase.org staging.wormbase.org].<br />
<br />
'''If you are not the developer who pushed the code for this issue''':<br />
* You can test out the changes and leave any feedback you have in the issue comments. <br />
* If you think this feature/fix is ready for production, you can '''remove the 'under testing' label''', or '''close the issue'''.<br />
<br />
==== Moving a feature to <code>master</code> (pass testing) ====<br />
First, check to see which issues are currently being tested:<br />
[https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']<br />
<br />
If this list is '''empty''', <code>staging</code> can be merged onto the <code>master</code>.<br />
<br />
In github, create a [https://github.com/WormBase/website/pull/new/staging pull request for staging]. Look at the '''Commits''' and '''Files changes'''. In the comment, summary all the features/issues introduced and make sure they are stable. Click on '''send pull request'''.<br />
<br />
Once the pull request is reviewed, it can be merged into the master branch.<br />
<br />
=== Hotfixes ===<br />
If a major bugfix is needed in production, create a hotfix branch from production. When finished, the branch needs to be merged back into <code>production</code> and <code>staging</code><br />
<br />
==== Begining a fix ====<br />
git checkout -b hotfix-issXXX production<br />
<br />
Fix the bug and commit the fix in one or more commits. Reference the github issue:<br />
git commit -m "Severe production bug<br />
* search redirecting to home page<br />
* fix #XXX"<br />
<br />
==== Closing the fix ====<br />
The fix needs to be merged back to both <code>production</code> and <code>staging</code><br />
git checkout staging<br />
git merge hotfix-issXXX<br />
<br />
git checkout production<br />
git merge hotfix-issXXX<br />
<br />
<br />
= Development Timeline =<br />
<br />
See: [https://docs.google.com/document/d/1zIOm95tV9A14n9xnkPkMgiOTGcOIzx161y9UbDZvfW4/pub WormBase Release Workflow]<br />
<br />
= Release Management =<br />
When production is ready to updated for release WSXXX:<br />
<br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:master...staging pull request from staging to master]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:production...master pull request from master to production]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Tag production branch with appropriate release name.<br />
<br />
<br />
git checkout production<br />
git tag -a WSXXX<br />
<br />
= Links =<br />
* [http://staging.wormbase.org staging site for testing]<br />
* [https://github.com/WormBase/website github repository]<br />
* [https://github.com/WormBase/website/issues github issue tracker]<br />
* [https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing workflow diagram]<br />
<br />
[[Category:Development General (Web Dev)]]<br />
[[Category:Getting Started (Web Dev)]]</div>Acabunochttps://wiki.wormbase.org/index.php?title=Development_workflow_-_webdev&diff=24268Development workflow - webdev2014-07-25T20:08:00Z<p>Acabunoc: /* Development Timeline */</p>
<hr />
<div>This page describes the development model used by the web development team at WormBase using git as our version control system. This includes our branching strategy and release management. We use git and GitHub to help us manage development.<br />
<br />
= Overview Diagram =<br />
[[File:Git_Workflow_-_WormBase4.png]]<br />
<br />
[https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing Editable version of the diagram]<br />
<br />
= Contributing =<br />
<br />
Whenever you begin work on a new issue you should create a new branch for it. Any new major features should branch off <code>staging</code>. Once the feature is ready for testing, it can be merged back into <code>staging</code>. These aren't necessarily branches in the main repository - can be local, or on a developer's fork. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Branch_stratgey Read more on our branching strategy]<br />
<br />
git checkout -b myFeature staging<br />
<br />
Now you can make your changes, commit some code. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Commit_Messages Read more on commit messages]<br />
<br />
<br />
When you're ready, you can push your branch to GitHub<br />
<br />
git push origin myFeature<br />
<br />
Continue making changes until your code is ready for testing. [http://wiki.wormbase.org/index.php/Development_workflow_-_webdev#Is_my_code_ready_for_testing.3F Is my code ready for testing?]<br />
<br />
When your code is ready, go to GitHub and create a Pull Request. [http://nathanhoad.net/git-workflow-forks-remotes-and-pull-requests More info on Pull Requests.]<br />
<br />
# Go to the repository where you pushed your changes<br />
# Switch to your branch (myFeature)<br />
# Click the green '''Compare & review''' button<br />
# After reviewing all the changes, click on '''Create pull request''' in the header to send the pull request<br />
# In the description, write a short summary of the issues and changes made along with some links for testing<br />
<br />
Wait for another member of the web development team to review and merge your pull request. If more changes are requested, you can push more commits to the same branch and it will be added to the pull request.<br />
<br />
Once your pull request is merged, locally bring in the changes and delete your issue branch<br />
git checkout staging<br />
git pull<br />
git branch -d myFeature<br />
<br />
Go to the original github issue:<br />
# Add the '''Under testing''' label to your issue<br />
# Comment on the issue to notify all involved that it is ready for testing. Add links for testing for the ease of testers.<br />
# Another member of the WormBase group will close the issue once they have tested it<br />
<br />
== Is my code ready for testing? == <br />
<br />
* Have written tests demonstrating the problem in the issue<br />
* Fix the problem (ie pass the tests)<br />
* Complete the issue as much as possible without curators seeing an example<br />
* Code style meeting the [http://wiki.wormbase.org/index.php/Coding_standards WormBase standards] (indentation, comments, no debug statements)<br />
<br />
== Commit Messages ==<br />
git commit -m "COMMIT MESSAGE GOES HERE"<br />
<br />
Keep your commit message as descriptive as possible, reference any issues affected, close any this resolves:<br />
This is a summary of my commit.<br />
* here is a breakdown of the different changes<br />
* mention github users (@tharris) when appropriate<br />
* related to #YYY<br />
* fix #XXX<br />
<br />
Here is a template originally written by Tim Pope at tpope.net:<br />
<pre><br />
Short (50 chars or less) summary of changes<br />
<br />
More detailed explanatory text, if necessary. Wrap it to about 72<br />
characters or so. In some contexts, the first line is treated as the<br />
subject of an email and the rest of the text as the body. The blank<br />
line separating the summary from the body is critical (unless you omit<br />
the body entirely); tools like rebase can get confused if you run the<br />
two together.<br />
<br />
Further paragraphs come after blank lines.<br />
<br />
- Bullet points are okay, too<br />
<br />
- Typically a hyphen or asterisk is used for the bullet, preceded by a<br />
single space, with blank lines in between, but conventions vary here<br />
</pre><br />
<br />
= Testing =<br />
All members of the core development team are expected to keep an eye on the current Pull Requests.<br />
<br />
= Branch Strategy =<br />
We use branches to help with our release management, testing strategy, and helping with parallel development among the team.<br />
<br />
== Main branches ==<br />
Inside the <code>WormBase/website</code> repository, there are three main branches: <code>master</code>, <code>staging</code> and <code>production</code>.<br />
<br />
* <code>master</code>: current, stable code. All new changes brought into master have been tested on [http://staging.wormbase.org staging.wormbase.org] and approved by either the curator requesting the change, or the development lead.<br />
<br />
* <code>staging</code>: any features/changes ready for testing should be pushed to the <code>staging</code> branch. This code gets pushed nightly to [http://staging.wormbase.org staging.wormbase.org].<br />
<br />
* <code>production</code>: the code currently in production. Branched off of <code>master</code> at each release.<br />
<br />
== Supporting branches == <br />
Other types of branches used can include feature branches and hotfixes. These branches are only intended to live until the new feature is merged into <code>staging</code> or the fix is completed.<br />
<br />
<br />
=== Feature branches ===<br />
Any new major features should branch off <code>staging</code>. Once the feature is ready for testing, it can be merged back into <code>staging</code>. These aren't necessarily branches in the main repository - can be local, or on a developer's fork.<br />
<br />
<br />
==== Testing issues ====<br />
All issues need to be tested and closed by at least one person who is not the developer who made the change. Ideally, it would be the curator asking for the feature/fix.<br />
<br />
'''If you would like to help test''':<br />
* Look at the [https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']. <br />
* All the changes for these issues are available for testing on [http://staging.wormbase.org staging.wormbase.org].<br />
<br />
'''If you are not the developer who pushed the code for this issue''':<br />
* You can test out the changes and leave any feedback you have in the issue comments. <br />
* If you think this feature/fix is ready for production, you can '''remove the 'under testing' label''', or '''close the issue'''.<br />
<br />
==== Moving a feature to <code>master</code> (pass testing) ====<br />
First, check to see which issues are currently being tested:<br />
[https://github.com/WormBase/website/issues?labels=under+testing&state=open open issues 'under testing']<br />
<br />
If this list is '''empty''', <code>staging</code> can be merged onto the <code>master</code>.<br />
<br />
In github, create a [https://github.com/WormBase/website/pull/new/staging pull request for staging]. Look at the '''Commits''' and '''Files changes'''. In the comment, summary all the features/issues introduced and make sure they are stable. Click on '''send pull request'''.<br />
<br />
Once the pull request is reviewed, it can be merged into the master branch.<br />
<br />
=== Hotfixes ===<br />
If a major bugfix is needed in production, create a hotfix branch from production. When finished, the branch needs to be merged back into <code>production</code> and <code>staging</code><br />
<br />
==== Begining a fix ====<br />
git checkout -b hotfix-issXXX production<br />
<br />
Fix the bug and commit the fix in one or more commits. Reference the github issue:<br />
git commit -m "Severe production bug<br />
* search redirecting to home page<br />
* fix #XXX"<br />
<br />
==== Closing the fix ====<br />
The fix needs to be merged back to both <code>production</code> and <code>staging</code><br />
git checkout staging<br />
git merge hotfix-issXXX<br />
<br />
git checkout production<br />
git merge hotfix-issXXX<br />
<br />
<br />
= Development Timeline =<br />
<br />
See: [https://docs.google.com/document/d/1zIOm95tV9A14n9xnkPkMgiOTGcOIzx161y9UbDZvfW4/pub WormBase Release Workflow]<br />
<br />
= Release Management =<br />
When production is ready to updated for release WSXXX:<br />
<br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:master...staging pull request from staging to master]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Create a new [https://github.com/WormBase/website/pull/new/WormBase:production...master pull request from master to production]. <br />
# Review all changes going into new release. Merge in the pull request. <br />
# Tag production branch with appropriate release name.<br />
<br />
<br />
git checkout production<br />
git tag -a WSXXX<br />
<br />
= Links =<br />
* [http://staging.wormbase.org staging site for testing]<br />
* [https://github.com/WormBase/website github repository]<br />
* [https://github.com/WormBase/website/issues github issue tracker]<br />
* [https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing workflow diagram]<br />
<br />
[[Category:Development General (Web Dev)]]<br />
[[Category:Getting Started (Web Dev)]]</div>Acabunoc