Testing Malevich installation
Malevich is a complex product which consists of several subsystems - a database, a web server, a notifier daemon, and a command-line client program. Each one of them can be either misconfigured, or not synchronized with other parts of the Malevich system, which could lead to occasional incorrect behavior. Sometimes the problems might not be unobvious, but crippling.
This document describes how to make sure that Malevich installation is fully functional.
First and foremost - important things about the installation
All Malevich components read and write data to the database.
Occasionally - not frequently - adding new functionality requires changes to the database. The deployment mechanism in Visual Studio makes database upgrade really painless - hit the 'Deploy' button, and the right thing happens - the database magically becomes the new version, and the data is preserved.
However, all other Malevich components treat the database as a structured store - they depend on the database having the right structure when they run. It is very, very
important to ensure that when the database is upgraded, all components are upgraded as well, and when any component is upgraded, the database is upgraded, too.
Another important point - the person who deploys Malevich must have administrative access to many things - the server on which IIS runs, the SQL server on which the database is deployed, etc. This gives the deployer very special rights, and it also makes testing the installation very difficult - what might work for the administrator, can easily fail for the other users
Therefore, the recommended that if you have a service account, use it for Malevich deployment. Do not give yourself Admin rights on SQL server where Malevich database is deployed, nor on the Windows Server where the web site is run.
Testing Malevich core
It is strongly recommended that the following steps be performed from a user account that does not have administrative rights on the Malevich installation - neither in SQL server, nor on the Windows Server that runs the web site.
Create a change list or a shelfset that includes 1 added, 2 edited, and 1 deleted file. Change the edited files, and submit the review.
If the review.exe fails, read the section on client setup in Installation and configuration
. Chances are that you're using TFS but have forgotten to copy the TFS DLLs from Visual Studio, or don't have PERFORCE or SD environment set up properly.
If review.exe fails to connect to the database, it is likely that you need to create a firewall exception for SQL Server and SQL Browser.
Change one of the edited files, revert the second one. Change the added file. Submit the review. Change both the edited and the added file again. Submit the review.
Go to Malevich web site from a client machine. If the web site does not appear and you are running on Vista, you need to create a firewall exception for IIS.
Open your change. Click on the added file. You will see multiple versions of this file. Make sure that you can select any version on the right, and eny version on the left, and the diff view works. If it doesn't, there could be several potential problems:
- You might not have the diff utility from unxutils installed. See Deploying the web site section of Installation and configuration.
- You might not have pointed the web site to where you have unxutils installed in web.config. See Deploying the web site section of Installation and configuration.
- Network service account might not have write rights to the Windows\Temp directory.
Note that if you are just looking at the differences between the base version of the edited file and some other version, everything might work even if you don't have unxutils installed or configured - in this specific case Malevich uses a shortcut. You need to test the diff between two non-base versions of an edited file, or two different versions of the added file.
After you have ascertained that the diff views work, create a few comments by clicking on various lines in a file view, and entering some text. Submit these comments, then go back to the change list view, and submit the review. Observe the user name under which the review iteration record will appear in the review history. If it says NETWORK SERVICE, this means that ASP.NET Impersonation is not enabled on the web site.
Testing review notifier
Run the following command:
ReviewNotifier.exe testsetup youralias
where youralias is a user name without domain suffix (or prefix). For example:
ReviewNotifier.exe testsetup alice
This connects to the database, queries some stats, and then sends a mail message to the account you've specified. Check your inbox - if you see the mail message, chances are notifier is working.