Differences between revisions 1 and 4 (spanning 3 versions)

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

QA-tagger setup

QA-tagger deployment

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

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

QAing the tagger

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

Go to devpad, and become the lpqateam user (you might need to file an RT requesting access to the lpqateam group);
Go to the ~/qa-tagger/qa folder;
Update the branch on devpad;
Perform a make clean and a make to regenerate the scripts;
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

-  ⇤ ← Revision 1 as of 2011-03-17 16:07:47 → 
  Size: 2098
  Editor: ursinha
  Comment: draft
+   ← 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 5:
-== qa-tagger deployment ==
+<<TableOfContents(3)>>
 Line 7:
-To deploy a new version of qa-tagger on devpad, follow these steps:
+== QA-tagger deployment ==
 Line 9:
-) Generate distributable package:
+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);
  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 12:
+Line 26:
-cd devel/
make dist
+  $ cd ~/qa-tagger/qa
  $ bzr up
  $ make clean && make
-Line 16:
+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 18:
+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 20:
+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 23:
+Line 42:
-tar xvf qatagger-r000.tgz
cd qatagger-r000
make install
+  $ cd ~/qa-tagger/current
  $ bzr up
  $ make clean && make
-Line 28:
+Line 47:
-) Setup instance to run:

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:

a) Copy over all the last-revno-* files from the "current" instance to the folder of the new deployment;
b) Create a link of the current-milestone file, placed on ~lpqateam/current-milestone:
{{{
$ ln -s /home/lpqateam/current-milestone current-milestone
}}}

c) Create a link to the place where the logs are kept:
{{{
$ 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. Now you should edit ~lpqateam's crontab commenting the "current" line and uncommenting the "qa" one.
+And you're done. Latest version running on production is now the QAed one.
-Line 46:
+Line 50:
-== cronjobs ==
+== Runtime files ==
-Line 48:
+Line 52:
-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.
+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.
-Line 52:
+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

launchpad development

Diff for "Foundations/QA/QATaggerSetup"