Status for Andrew DeFaria

Creating a dev schema is not that difficult. Note you can create a dev schema in the production schema repo or in a dev schema repo. The later is a just a bit safer as it is a bit more isolated.

To create a dev schema from the CQ Designer, right click on the schema repo and select New: Schema. We are creating a new schema by basing it off of an existing schema. Expand the + sign and select the version that you wish to base your new schema off of. Right now there is only Version 1. Select next and name your schema. I suggest that you use your username (e.g. adefaria) indicating that we are the owner of this dev schema. Enter comments if you like and then Finish.

After the schema is created it will ask you if you want to associate this with a database. You could select Yes and then go though naming your database and connecting it to an existing user database but chances are you don't have one of those yet. So select No for now. You now have a development schema.

Creating a Test Database

You must create an empty database on the database server. Use RDP to get a remote desktop there and run the SQL Server Management Studio and connect to the database server engine.

Next right click on databases and select New Database. Name your database. The convention for test databases is <schemaname>_<id>. For our personal test databases again I'd suggest using your user ID so I will create <schemaname>_adefaria for me.

Setting the db_owner and schema owner

In MSSQL we need to set the dbowner and the schema for this new database. Expand the folder tree (+) on your newly created database (MobDev_adefaria) then right click on Security and select New: User. Type <dbadmin> in the User Name edit box and then select and copy this string. We'll need it several times more in this process. Paste this into the Login name and Default Schema and then toggle on db_owner in both the Schemas owned by this user and Database role membership boxes then select OK.

Next right click on Security again and select New: Schema. Paste <dbadmin> into Schema Name and Schema Owner and click OK.

Now you have an empty database that you can associate with your schema.

Associating your new test database with your dev schema

Go back to CQ Designer and right click on your development schema again and select Show: User Databases. You should see a list of databases. Right click on an empty area and select Create Database. Seems odd to call it create database when the database has already been created - it really means "take this schema and it's definition of what should be in the user database and apply that definition/schema to my newly created empty database".

Give this database a Logical Database Name. Alas we only have 5 characters. I just use my initials - apd - short and simple. Add comments if you like. We use MSSQL for the database vendor. Then toggle Database Type to Test Database. We already have a production database in our dev schema repo then select next.

Now we fill in Physical Database Name with the name of the database (<schemaname>_adefaria) and the Database Server . Then paste that <dbadmin> into Administrator User and Administrator Password (See I told you you'd need it!) then Next and Next again.

Now we need to expand the adefaria (your dev schema) and select which version you want this new test database to start with. Select Version 1 and Finish.

Clearquest Designer now goes out and creates all the necessary tables and transfers all of the necessary data, hook scripts, etc. from Version 1 of the dev schema adefaria into your database. Get coffee...

After the database is created follow the steps at Seeding a test database to seed your test database with some test data.

Posted by at 9:08 PM | Permalink | TrackBacks (0)

When you have multiple Clearquest Designers you quickly realize that you cannot easily do parallel development of the schema. The best way to do this is to work through a development schema repository and to create development schemas for each schema designer. To create a development schema repository you should first create an empty database for Clearquest to work in. You can create an empty database by following the instructions for Creating a Test Database. Next you must use the Clearquest Maintenance Tool to create a new Schema Repository:

• Start the Clearquest Maintenance Tool
• Select Schema Respository: Create
• The Maintenance Tool then asks you to fill out information regarding the location of your schema database. Fill in information about the database server and Administrator Name and password. Do not create a sample database at this time. The Clearquest Maintenance tool will take some time to set up the new schema repository.

Exporting a CQProfile.ini for this new Development Schema Repository

In order to see this new development schema repository you should export the schema repository from the Clearquest Maintenance Tool. This exported cqprofile.ini can be shared with out Schema Developers who would import the .ini file into their environment using the Clearquest Maintenance Tool. You export the cqprofile.ini by selecting File: Export Profile. You need only select the new repository you created.

Click on the "..." button to select where to store the .ini file and what it's name will be - I used C:\Cygwin\tmp\MPSDev.ini and click Finish. This file can be passed to your fellow Schema Developers.

Importing Users

Your new development schema repo has no users in it except a default set of users including the "admin" user (with no password). Run the User Administration tool on production (MCBU) and export all of the users. Run the User Administration tool again on the new development schema repo (e.g. MPSDev) and import the users.

Clean up Unnecessary Schemas

Now's a good time to remove additional default schemas in your development schema repo like Common, DefectTracking, Enterprise, etc. You cannot delete the Blank schema.

Seeding the Development Schema Repo with the Latest Version from Production

One trick to seed your new development schema repo with a recent version of the production schema is to create a new development schema in the production schema repo based off of the latest version of the production schema. Then export that whole schema of the new development schema and import it into the new development schema repo. You will only have the history of the latest version of the schema but that's OK for development purpose. Make sure you specify an appropriate Schema Name and Comment when you export the schema from production:

Note: We are giving this schema the name MPSDev because that's what we want it to be called in the new development schema repo. Also, the comment is appropriate when we will be looking at it in the MPSDev development schema repo.

Do not associate a database with this schema, there's no reason. We don't care as we are only using this to exportschema from production -> development schema repo. We'll create databases there. We don't need to check out this schema either.

Exporting the Schema from Production

We assume you have created a new development schema in the production schema repo based off of the tip of the production database. You need to export that with:

Where <schemaname> is the name of the development schema name you created in the production schema repo

Importing the Schema into the Development Schema Repo

Next we import this full.schema of only the tip of production to seed a development schema in the development schema repo.

Oops! We need to import these packages into our new schema. Right click on your new development schema repo in Clearquest Designer and select Install Package. Expand the EmailPlus and select 2.1 to install that. Repeat this for Resolution and Attachments. Repeat the cqload importschema.

Remove Old Schema in Production Repo

You can remove the schema you created above in the Production repo as it is no longer needed.

Create Dev Schemas

You are now free to create development schemas in the new development schema repo as described Creating a Development Schema as well as test databases and seeding them.

Posted by at 2:41 PM | Permalink | TrackBacks (0)

Programming complex systems is... well... complicated. You need to focus on the task at hand and be able to see the trees from the forest as they say. That's why I like to eliminate as much what I call syntactic sugar from the language. Syntactic sugar are ornaments, special characters and restating the obvious or default that makes your mind drift from the problem at hand to how to formulate syntactic sugar. Additionally such sugar takes time to type in, is prone to errors if you don't get it right and usually are comprised of characters that, as a touch typist, you have to often stretch to reach on the keyboard.

Here's an example. Recently I came across the following code:

Now that takes a some time to parse... (Did you see the comment buried in there?) And here's the same code with the syntactic sugar removed:

which do you find easier to read?

Notes:

• Surrounding hash keys with '' is unnecessary unless you use special characters in the key name like spaces and '-'. The '_' character is OK (the Perl interpreter views '-' as a possible subtraction). Use '' for hash keys only when necessary.
• The additional '->' operators are unnecessary. The first one is necessary since $self is a hashref, but after that you don't need them - why type them?
• The delete call need not have (). Granted, delete is a function and some people field all function should have () even if there are no parameters. And yet even people who feel this way rarely use () on Perl builtins like print and die. If you define your subroutines before they are used you can call them without ().
• There's no reason to include "if (exists $self->{'cqc'}->{'fields'}->{'PCP_ID'})". First off, if clauses that follow the statement do not need (). Even "exists" is unnecessary as if it is omitted the if statement works the same anyway. Finally, delete $hashref->{unknown} will not error out if $hashref->{unknown} doesn't exist.

Posted by at 8:13 PM | Permalink | TrackBacks (0)