History: client_documentation

Source of version: 11 (current)

!Client documentation

!!Contacts 
- XXX Project Manager Tel, email, skype 
- XXX Account Manager Tel, email, skype

!!Case reporting process
In order to help ensure an efficient and fast process for working through cases, please follow the following lines.

!!!Client sets priority. 
- High: urgent task, should be undertaken first (and stop the other tasks in progress)
- Normal: undertake after 'High'
- Low: undertake after normal, when there is nothing else to do

!!!Client to choose Type
- Bug: a behavior which is not working as expected 
- Question: a question about a functionality
- Feature Request: a new case which was not in the initial specification
- General Task: other inquiries
 
!!!Client to provides a Title along following lines 
You should be as precise and clear as possible when you give a summary (also called title) to the bug report. 
 
- Bad title example: Problem in the forum
- Goog title: Error on replying to a thread, can't click on post button   


!!!Client provides a description (Body) 

1. Provide the page that the issue is located on (copy paste the URL).
1. A step-by-step description on how to reproduce the issue (click here and here and do this and that etc...).
1. Provide your environment information (Windows XP/Vista, Firefox, Internet Explorer, Version 7...).
1. Note: _Ideally,_ only technical personnel can add cases (in order to reduce time and energy required in clarification etc).
1. Client does not initially assign the case, rather, {COMPANY} assigns the case.
1. The project manager will comment and assign back to client if he needs more information. When info are provided, client assigns back to the project manager.
1. At completion, the project manager will assign the case back to client with a comment "please review". 
1. Client will test the result on UAT server.
1. Client will reassign back to the project manager if there is still an issue, or otherwise change the case status to "Resolved".

!!Maintenance
On both UAT and production server, our Sysadmin team will proceed to weekly server maintenance operations on every Sunday evening from 22h to 23h UTC time. It can include to restart some services and servers and so your website can be unavailable for a few minutes.

!!The wonderful story of bugs life (By Alex Gibson)
Once upon a time there was a bug. This bug was not a nasty, horrible bug, but rather just an annoying little creature that sometimes made things a little unpleasant. Of course there are nasty horrible bugs that make everything go horribly wrong, but most bugs are little and just a bit annoying. There are also other things that live amongst bugs. Things like questions, feature requests and general tasks. These other things are also important, but they are for another story. This story is about how a bug goes from a being little baby bug into a big, beautiful butterfly.

Bugs are little when they are new. They require an eye for detail. When a bug is found its usually hard to find again by someone else unless good instructions are given as to where it is. When someone finds a little bug, they need to make notes, take a photo, make a map and write a clear explanation for others to use. When this is done well, that little bug can be found more easily.

Once a bug is found, the information to find it again can be put into a case. This allows the budding bug catcher to use all their wits and skills to track it down. Bug catchers are a special breed. They know a lot about bugs. They are experts in finding them, working out how they live. They will find them put them in a jar and study them closely. They will look at their environment, how they interact with with other bugs. They will look at how they hurt and hinder their environment, but they will also look at what they are doing to make it work. Sometimes, just killing bugs is tempting, but this kind of reckless approach can only lead to other species of bugs breeding. This is why a careful approach is needed. This careful approach is what this story is about. It is about turning the bugs into beautiful butterflies, that everyone can admire.

A bug catcher needs clear information to find a bug. She will then need to find the bug and put it in a jar. Then the bug catcher can study the bug. Often the bug catcher will know what that bug is once they can look at it. They know a lot about bugs and they have seen many bugs before. Occasionally they will realise they are looking at a whole new species. This can be exciting for a bug catcher. They will go through a process of cataloging, testing and recording what they find in a case.

This is procedure when someone thinks they have found a new bug:

The person:

    * Looks at their requirements and figures out if this is a bug or some other thing.
    * Confirms that it is a bug and not a question, feature request or general task.
    * Goes to the atrium and and confirms that this is not an existing bug with an existing case.
    * Decides if the bug priority is high, normal or low. (note that if all bugs are high priority, then normal becomes meaningless)
    * Writes a case for the bug describing how and where it was found.
    * Once this is done, the bug catcher must be notified so that sh can do her job.

This is the procedure a bug catcher uses when someone finds a bug and creates a case.

The bug catcher:

    * Uses the information in the case to find the bug for herself.
    * They might know about the bug in which case they will fix the bug (and make its status 'resolved')
    * They may not know about this particular bug and have to do some research.
    * They may know about the bug, but it cannot be solved. This can be frustrating for everyone, but some problems just cannot be solved... we all know this, its like death or taxes. They just are.
    * The bug catcher will notify the person who found the bug about what they now, or found out or did.
    * Once a case is considered resolved, it is then up to the person who is responsible for the environment to decide if they are satisfied with the resolution, or if new information or decisions have been made to reopen the case.
    * Once this procedure is done, the case can usually be closed. And when the case is closed the bug catcher can move on and work with other people and other bugs, as is there lot in life.

And when a case is closed the bug transforms magically into a big, beautiful butterfly. And this is the story of a bugs life.

!!Recommendation for production environment

^
- UNIX/Linux environment
* It's possible to use Windows but we strongly recommend a UNIX/Linux environment.

- Apache 2.x
* Modules: mod_rewrite extension to allow for clean URLs.
* Vhost example:

<VirtualHost *:80>
ServerName drupal.dev
ServerAlias www.drupal.dev
ErrorLog /home/web/drupal/logs/error_log
CustomLog /home/web/drupal/logs/access_log combined
DocumentRoot /drupal
<Directory /drupal>
        Options Indexes MultiViews SymLinksIfOwnerMatch
        AllowOverride All
        Order allow,deny
        Allow from all
</Directory>
</VirtualHost>

- Mysql 5.x
* Eventually binary logs are activated for backup.
* Created user must be able to: SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES.

- PHP 5.2.x
* recommended php.ini: http://cvs.php.net/viewvc.cgi/php-src/php.ini-recommended?revision=1.179...

- Crontab
* Get http://server.dev/cron.php every 10 minutes
* Example:
[root@server ~]# crontab -l
*/10 * * * * wget -q http://server.dev/cron.php

- Migration
* We use subversion along the development with branches.
* The easy way to install and update the website is to query our versioning server to checkout our trunk (stable version) by SSH on port 61326 (we'll need you SSH public key). We can also provide a tarball.
* To checkout:
user@vm:~$ cat .ssh/config
Host *XXX.com *XXX.org
   Port      61326
user@vm:~$ svn checkout svn+ssh://user@XXX.com/home/svn/XXX/trunk .
* SQL: we will include the lastest dump version with the files.^

SourceHistory

- A simple and Open process for web team management - Find Register Log in Username: Password: I forgot my password Register
	Sidebar Menu Home Search Categories Wiki Wiki Home Last Changes List Pages Orphan Pages Sandbox Multiple Print Structures Articles Articles Home List Articles Forums List Forums File Galleries List Galleries	History: client_documentation View page Source of version: 11 (current) !Client documentation !!Contacts - XXX Project Manager Tel, email, skype - XXX Account Manager Tel, email, skype !!Case reporting process In order to help ensure an efficient and fast process for working through cases, please follow the following lines. !!!Client sets priority. - High: urgent task, should be undertaken first (and stop the other tasks in progress) - Normal: undertake after 'High' - Low: undertake after normal, when there is nothing else to do !!!Client to choose Type - Bug: a behavior which is not working as expected - Question: a question about a functionality - Feature Request: a new case which was not in the initial specification - General Task: other inquiries !!!Client to provides a Title along following lines You should be as precise and clear as possible when you give a summary (also called title) to the bug report. - Bad title example: Problem in the forum - Goog title: Error on replying to a thread, can't click on post button !!!Client provides a description (Body) 1. Provide the page that the issue is located on (copy paste the URL). 1. A step-by-step description on how to reproduce the issue (click here and here and do this and that etc...). 1. Provide your environment information (Windows XP/Vista, Firefox, Internet Explorer, Version 7...). 1. Note: _Ideally,_ only technical personnel can add cases (in order to reduce time and energy required in clarification etc). 1. Client does not initially assign the case, rather, {COMPANY} assigns the case. 1. The project manager will comment and assign back to client if he needs more information. When info are provided, client assigns back to the project manager. 1. At completion, the project manager will assign the case back to client with a comment "please review". 1. Client will test the result on UAT server. 1. Client will reassign back to the project manager if there is still an issue, or otherwise change the case status to "Resolved". !!Maintenance On both UAT and production server, our Sysadmin team will proceed to weekly server maintenance operations on every Sunday evening from 22h to 23h UTC time. It can include to restart some services and servers and so your website can be unavailable for a few minutes. !!The wonderful story of bugs life (By Alex Gibson) Once upon a time there was a bug. This bug was not a nasty, horrible bug, but rather just an annoying little creature that sometimes made things a little unpleasant. Of course there are nasty horrible bugs that make everything go horribly wrong, but most bugs are little and just a bit annoying. There are also other things that live amongst bugs. Things like questions, feature requests and general tasks. These other things are also important, but they are for another story. This story is about how a bug goes from a being little baby bug into a big, beautiful butterfly. Bugs are little when they are new. They require an eye for detail. When a bug is found its usually hard to find again by someone else unless good instructions are given as to where it is. When someone finds a little bug, they need to make notes, take a photo, make a map and write a clear explanation for others to use. When this is done well, that little bug can be found more easily. Once a bug is found, the information to find it again can be put into a case. This allows the budding bug catcher to use all their wits and skills to track it down. Bug catchers are a special breed. They know a lot about bugs. They are experts in finding them, working out how they live. They will find them put them in a jar and study them closely. They will look at their environment, how they interact with with other bugs. They will look at how they hurt and hinder their environment, but they will also look at what they are doing to make it work. Sometimes, just killing bugs is tempting, but this kind of reckless approach can only lead to other species of bugs breeding. This is why a careful approach is needed. This careful approach is what this story is about. It is about turning the bugs into beautiful butterflies, that everyone can admire. A bug catcher needs clear information to find a bug. She will then need to find the bug and put it in a jar. Then the bug catcher can study the bug. Often the bug catcher will know what that bug is once they can look at it. They know a lot about bugs and they have seen many bugs before. Occasionally they will realise they are looking at a whole new species. This can be exciting for a bug catcher. They will go through a process of cataloging, testing and recording what they find in a case. This is procedure when someone thinks they have found a new bug: The person: * Looks at their requirements and figures out if this is a bug or some other thing. * Confirms that it is a bug and not a question, feature request or general task. * Goes to the atrium and and confirms that this is not an existing bug with an existing case. * Decides if the bug priority is high, normal or low. (note that if all bugs are high priority, then normal becomes meaningless) * Writes a case for the bug describing how and where it was found. * Once this is done, the bug catcher must be notified so that sh can do her job. This is the procedure a bug catcher uses when someone finds a bug and creates a case. The bug catcher: * Uses the information in the case to find the bug for herself. * They might know about the bug in which case they will fix the bug (and make its status 'resolved') * They may not know about this particular bug and have to do some research. * They may know about the bug, but it cannot be solved. This can be frustrating for everyone, but some problems just cannot be solved... we all know this, its like death or taxes. They just are. * The bug catcher will notify the person who found the bug about what they now, or found out or did. * Once a case is considered resolved, it is then up to the person who is responsible for the environment to decide if they are satisfied with the resolution, or if new information or decisions have been made to reopen the case. * Once this procedure is done, the case can usually be closed. And when the case is closed the bug catcher can move on and work with other people and other bugs, as is there lot in life. And when a case is closed the bug transforms magically into a big, beautiful butterfly. And this is the story of a bugs life. !!Recommendation for production environment ^ - UNIX/Linux environment * It's possible to use Windows but we strongly recommend a UNIX/Linux environment. - Apache 2.x * Modules: mod_rewrite extension to allow for clean URLs. * Vhost example: <VirtualHost :80> ServerName drupal.dev ServerAlias www.drupal.dev ErrorLog /home/web/drupal/logs/error_log CustomLog /home/web/drupal/logs/access_log combined DocumentRoot /drupal <Directory /drupal> Options Indexes MultiViews SymLinksIfOwnerMatch AllowOverride All Order allow,deny Allow from all </Directory> </VirtualHost> - Mysql 5.x Eventually binary logs are activated for backup. * Created user must be able to: SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES. - PHP 5.2.x * recommended php.ini: http://cvs.php.net/viewvc.cgi/php-src/php.ini-recommended?revision=1.179... - Crontab * Get http://server.dev/cron.php every 10 minutes * Example: [root@server ~]# crontab -l /10 * * * wget -q http://server.dev/cron.php - Migration * We use subversion along the development with branches. * The easy way to install and update the website is to query our versioning server to checkout our trunk (stable version) by SSH on port 61326 (we'll need you SSH public key). We can also provide a tarball. * To checkout: user@vm:~$ cat .ssh/config Host XXX.com XXX.org Port 61326 user@vm:~$ svn checkout svn+ssh://user@XXX.com/home/svn/XXX/trunk . * SQL: we will include the lastest dump version with the files.^ SourceHistory
RSS: Wiki Articles File Galleries Forums This content is licensed under a Creative Commons Attribution 3.0 Unported License offered by Pierre Doleans and sponsored by Collabforge - Website powered by Tiki Wiki

Sidebar

Menu

History: client_documentation

Source of version: 11 (current)