Diff for "QA/QATaggerSetup"

Not logged in - Log In / Register
Differences between revisions 3 and 4
⇤ ← Revision 3 as of 2011-03-17 22:00:23 →
Size: 2554
Editor: ursinha
Comment: better formatting
← Revision 4 as of 2011-06-24 21:40:36 → ⇥
Size: 3316
Editor: ursinha
Comment: Changing instructions to the new qa-tagger deployment way
Deletions are marked like this. Additions are marked like this.
Line 9: Line 9:
To deploy a new version of qa-tagger on devpad, you have to follow these steps: To deploy a new version of qa-tagger on devpad, you have to follow three steps:
Line 11: Line 11:
=== Generate a distributable package ===  1. Make sure the desired revision is current on the qa-tagger devel branch.
 2. QA!
 3. Apply changes to production.

=== QAing the tagger ===

You need to update the "qa" branch on devpad to do that. Steps to go:

  1. Go to devpad, and become the {{{lpqateam}}} user (you might need to file an RT requesting access to the lpqateam group);
  1. Go to the {{{~/qa-tagger/qa}}} folder;
  1. Update the branch on devpad;
  1. Perform a make clean and a make to regenerate the scripts;
  1. Profit!
Line 14: Line 26:
cd devel/
make dist		   $ cd ~/qa-tagger/qa
  $ bzr up
  $ make clean && make
Line 18: Line 31:
This will download all dependencies and generate a tarball named "qatagger-r<current revno>.tgz". Now you should edit ~lpqateam's crontab commenting the "current" line and uncommenting the "qa" one. The invoked script is {{{tag-nator-o-matic.sh}}}, which runs {{{./bin/tag-bugs}}} to each project and branch.
Line 20: Line 33:
=== Install on devpad === '''Note:''' QA-tagger generates the reports and place them always in the same folders, unless you tell it not to. So, while doing QA, users will see the reports generated by the code being QAed. The thing about having "qa" and "current" is that it's easy to switch back to a working version. If QA fails miserably, just change the cron entry back to "current" version, and you're safe.
Line 22: Line 35:
Copy the tarball over to ~lpqateam/qa-tagger/ on devpad, extract that, and run a make install. '''Note 2:''' QA-tagger processes the revisions sequentially. So, if you notice a breakage and want QA-tagger to reprocess revisions, go to the proper {{{last-revno-<project>-<branch>}}} file and change it to the last successfully processed revision. This way, QA-tagger will start processing from this one in the next run.

=== Deploying to production ===

Once you have QAed the script enough, and it's proven working well, do the same updating process in the "current" folder:
Line 25: Line 42:
tar xvf qatagger-r000.tgz
cd qatagger-r000
make install		   $ cd ~/qa-tagger/current
  $ bzr up
  $ make clean && make
Line 30: Line 47:
=== Setup instance to run === And you're done. Latest version running on production is now the QAed one.
Line 32: Line 49:
To run properly, qa-tagger uses a set of files named last-revno-<project>-<branch>. They store the last processed revision for each project and branch. In order to "upgrade" qa-tagger, follow these steps:
Line 34: Line 50:
==== Copy runtime files ==== == Runtime files ==
Line 36: Line 52:
Copy over all the last-revno-* files from the "current" instance to the folder of the new deployment. To run properly, qa-tagger uses a set of files named {{{last-revno-<project>-<branch>}}}. They store the last processed revision for each project and branch. The revision files are in {{{~/qa-tagger/revisions}}}, and each running instance has links pointing to those files. Usually you don't have to do anything about it, but if the links aren't there, just create them.
Line 38: Line 54:
{{{
$ cp /home/lpqateam/qa-tagger/current/last-revno-* /home/lpqateam/qa-tagger/qatagger-r000/
}}}		 Same happens to the qa-tagger logs. Logs are in the {{{~/public_html/qa_reports/logs}}} folder. There should be a link in the current branch; if not, just create it.
Line 42: Line 56:
==== Link the current milestone ====

Create a link of the ~lpqateam/current-milestone file on qa-tagger's instance root:
{{{
$ ln -s /home/lpqateam/current-milestone current-milestone
}}}

==== Link qa-tagger logs ====

Create a link of the logs on qa-tagger's instance root:
{{{
$ ln -s /home/lpqateam/public_html/qa_reports/logs logs
}}}

Current production version on devpad is a symlink called "current" pointing to the last version. To QA the new instance, create a new link "qa" pointing to the revision you just setup.
{{{
$ cd ~lpqateam/qa-tagger
$ rm -f qa
$ ln -s /home/lpqateam/qa-tagger/qatagger-r000 qa
}}}

Now you should edit ~lpqateam's crontab commenting the "current" line and uncommenting the "qa" one. The invoked script is tag-nator-o-matic.sh, which runs ./bin/tag-bugs to each project and branch.
 This linking approach was created to avoid having to copy runtime files every time a new branch was deployed. This way you only need to worry about updating the branch, and nothing else.
Line 68: Line 60:
The only crontab job running is the one that triggers the script. There are two entries in the ~lpqateam crontab, one for the "qa" instance and another for a "current" instance. Only thing needed is to switch between them, never forgetting to copy over all the last-revno-* files from the last run to the instance that should be activated. The only crontab job running is the one that triggers the script. There are two entries in the ~lpqateam crontab, one for the "qa" instance and another for a "current" instance. Only thing needed is to switch between them.
Line 72: Line 64:
*/15 * * * * cd $HOME/qa-tagger/current && ./tag-nator-o-matic.sh
#*/15 * * * * cd $HOME/qa-tagger/qa && ./tag-nator-o-matic.sh		 */10 * * * * cd $HOME/qa-tagger/current && ./tag-nator-o-matic.sh
#*/10 * * * * cd $HOME/qa-tagger/qa && ./tag-nator-o-matic.sh

QA-tagger setup

This page describes how to deploy new code to qa-tagger production instance, how and which cronjobs are configured, how to deploy and to QA new deployments.

Contents

  1. QA-tagger setup
    1. QA-tagger deployment
      1. QAing the tagger
      2. Deploying to production
    2. Runtime files
    3. Cronjobs

QA-tagger deployment

To deploy a new version of qa-tagger on devpad, you have to follow three steps:

  1. Make sure the desired revision is current on the qa-tagger devel branch.
  2. QA!
  3. Apply changes to production.

QAing the tagger

You need to update the "qa" branch on devpad to do that. Steps to go:

  1. Go to devpad, and become the lpqateam user (you might need to file an RT requesting access to the lpqateam group);

  2. Go to the ~/qa-tagger/qa folder;

  3. Update the branch on devpad;
  4. Perform a make clean and a make to regenerate the scripts;
  5. Profit! 

  $ cd ~/qa-tagger/qa
  $ bzr up
  $ make clean && make

Now you should edit ~lpqateam's crontab commenting the "current" line and uncommenting the "qa" one. The invoked script is tag-nator-o-matic.sh, which runs ./bin/tag-bugs to each project and branch.

Note: QA-tagger generates the reports and place them always in the same folders, unless you tell it not to. So, while doing QA, users will see the reports generated by the code being QAed. The thing about having "qa" and "current" is that it's easy to switch back to a working version. If QA fails miserably, just change the cron entry back to "current" version, and you're safe.

Note 2: QA-tagger processes the revisions sequentially. So, if you notice a breakage and want QA-tagger to reprocess revisions, go to the proper last-revno-<project>-<branch> file and change it to the last successfully processed revision. This way, QA-tagger will start processing from this one in the next run.

Deploying to production

Once you have QAed the script enough, and it's proven working well, do the same updating process in the "current" folder: 

  $ cd ~/qa-tagger/current
  $ bzr up
  $ make clean && make

And you're done. Latest version running on production is now the QAed one.

Runtime files

To run properly, qa-tagger uses a set of files named last-revno-<project>-<branch>. They store the last processed revision for each project and branch. The revision files are in ~/qa-tagger/revisions, and each running instance has links pointing to those files. Usually you don't have to do anything about it, but if the links aren't there, just create them.

Same happens to the qa-tagger logs. Logs are in the ~/public_html/qa_reports/logs folder. There should be a link in the current branch; if not, just create it.

This linking approach was created to avoid having to copy runtime files every time a new branch was deployed. This way you only need to worry about updating the branch, and nothing else.

Cronjobs

The only crontab job running is the one that triggers the script. There are two entries in the ~lpqateam crontab, one for the "qa" instance and another for a "current" instance. Only thing needed is to switch between them. 

# qa bug tagging tool 
*/10 * * * * cd $HOME/qa-tagger/current && ./tag-nator-o-matic.sh
#*/10 * * * * cd $HOME/qa-tagger/qa && ./tag-nator-o-matic.sh

QA/QATaggerSetup (last edited 2011-07-21 19:20:18 by matsubara)