Good habits are important in every area of our lives. For example, the good habit of checking your blind spot while driving can save your life. The habit of remembering your spouse’s birthday can save your marriage. The habit of washing your hands before eating can save your health.
Good habits in App Designer may not save your life (unless you have a pretty mean boss who can’t stand lost objects), marriage, or health, but they can save a lot of frustration at migration time.
Here are a few thoughts that might improve your PeopleTools development skills.
Habit 1: Understand projects for what they are
Projects in App Designer are easily misunderstood at first. They are nothing more than a list of definitions. From the database point of view, a project is not much more than the PSPROJECTITEM table. A quick query of the table will show that the project does not save any more details about each definition than just its name.
A novice developer is tempted to think he can back up a definition by saving it in another project. PeopleTools does not work that way. The only way the JOB record could be different between Project A and Project B is if it were copied to a file or another database.
The primary purpose of a project is for migrating from one database to another. All changes in App Designer should be done in the development environment, and the project provides the vehicle for getting that development into a testing environment and eventually into production.
As a result, a good developer does not put extra definitions in the project list just for quick access. Only definitions that have been changed should go in the project as those are the ones that need to be copied.
Taking it a step further: Know your organization’s development standards. Some groups may create a new project for every new development effort, while other teams may dedicate a project for each feature, migrating that same feature project for each new effort changing that feature. If a standard has yet to be determined, consider following both methods. Create a project for each new initiative name according to a ticket number with details on what change was made. Upon migration, merge that project into the feature project. As a result, using “Find Definition References” on a definition will show both what features are connected to that definition and what changes it has undergone.
Another thing to watch out for is preferences on certain types of objects. Menus, permission lists, and roles are prime examples. Some migration teams prefer to document and make those changes manually so as to avoid migrating unwanted changes.
Habit 2: F7 every time you save
The longer a development effort lasts, the harder it is for developers to remember what they changed and how to get it into the testing environment. So, a good developer has the habit of keeping track along the way.
The best habit is to press F7 every time after saving any definition. F7 is the shortcut for Insert > Current Definition into project. Also, remember to save the project often, maybe after every F7 to avoid losing that work.
App Designer has an option under Tools > Options to “Insert Definition into Project when definition is modified and saved, or deleted”. That is good at capturing all of the changes made, but it does not make the developer as aware of the project as necessary.
For example, if the developer adds a translate value to a field, App Designer will put the field in the project, not the translate value. Or, if a developer makes a change to a delivered PeopleCode program just for debugging purposes, App Designer will add that delivered object to the project increasing the chance that it gets migrated to production. A developer has better habits if he uses the option to “Insert Definition in Project Manually”.
Taking it a Step Further: Some definitions require adding multiple parts individually. Translate values and Application Engines are prime examples. Learn those definition types and make sure to insert the parts that changed. If creating a new field, make sure not to forget to add both the field definition and the translate value. If only changing the translate values, do not insert the field definition into the project.
Application Engines are designed so that migration teams can copy each section individually. If the App Engine Program is brand new, use the Insert > Definitions Into Project and the related definition feature to insert the whole program and all of the related definitions. When editing the steps of the App Engine, make sure to use F7 on each SQL or PeopleCode program changed.
Habit 3: Do not use Save All
Many developers mistake the fourth icon on the toolbar from the left as the Save Project shortcut. It is true that it will save the project, but it also saves all of the open definitions at that time. Most of the time, developers want everything saved, but sometimes that can cause problems.
This is a likely scenario. A developer opens up the EFF_STATUS field to see the translate values. Opening the field properties triggers App Designer to mark this window as changed even though no changes were made. The developer proceeds to switch over to the SQL statement he was coding and make the changes based on what he learned. Once everything is done, he inserts the SQL into the project and presses the Save All button. App Designer saves the EFF_STATUS field. Although no changes really exist, App Designer changes the last update user from PPLSOFT to the developer’s user id. This marks this field “customized” and adds extra analysis effort during an upgrade.
Taking it a Step Further: App Designer does not have a keyboard shortcut for saving just the project. Using the keyboard letters for the menu will do the trick almost as easy. Master Alt, F, then V to make for quick easy saving of the project.
Habit 4: Plan for migration from the beginning
No development is worth anything until the team can get it out of Dev! A customization or bolt on could fold your laundry, balance the budget with bonuses for everyone, and get the kids off to school on time in the morning, but if it does not perform the same in production, it is not worth a hill of beans.
Migration is not usually just moving the project from one environment to another. Many times data needs to be moved, security granted, or manual tasks completed. Why wait until the end when remembering the different parts is hard?
At the very beginning of every development effort, create a folder somewhere to put all of the data mover scripts and documentation. Then, create a document that lists the steps required to migrate the development. Throughout the development process, as the need for a data mover script arises, add it to the document. This way, at the end, preparing for migration is as simple as proofreading a document and passing on the necessary files.
Taking it a Step Further: All of the definition details are stored in the database including the project information. Many organizations want the list of definitions associated with a ticket included in the documentation. Forcing a developer to manually compile this list is a waste of time. Instead, create a report off of the PSPROJECTITEM table to include in the documentation.
The tables can be used to double check the project and migration. At Gideon Taylor, we have a “STOMP” tool that allows for searching for definitions based on last update user id and last update date/time. The tool will list definitions not already in a project.
Habit 5: Backup
A good development environment has regular database backups. The system administrator should always know what efforts are in progress before doing refreshes. But, that is not real life. Especially in development environments, backups are not always current or do not go back far enough. Especially when testing takes a long time or many projects are in progress, things get missed on refreshes.
So, developers should make their own backups of work just in case. In App Designer, use Tools > Copy Project > To File to save work to your file system. For data, use Data Mover to export any important data as well. If a migration plan has already been started, backing up should be fairly easy to run through.
Taking it a Step Further: Both App Designer and Data Mover have command line parameters. PeopleBooks describes how the parameters can be crafted to export a project to file or to run a data mover export script. Especially, for simple projects, the backup could be as easy as double clicking on a batch script.
