MKS Implementer 2006 Administration Guide

Chapter 2: Understanding Implementer
Change Request Process
58
Step One: Log Change Request
Enter change requests (problems or program modification requests) as MKS Integrity issues.
Step Two: Initiate and Complete Development
Using MKS Integrity issues, assign work to developers.
The developer checks out the required source in either Implementer or MKS Source,
depending on the platform location and tool appropriateness of the objects needing to be
changed.
An example of mixed development is a client/server application where the iSeries is used as
the server. The server programs are written in RPG and the client side is written in C, Visual
Basic, or Java. In this scenario, a single issue could result in a development effort on both
platforms, with Implementer supporting the OS/400 side and MKS Source supporting the
rest.
The developers finish the work. MKS Source-side developers check in a change package to
the appropriate source project, and specify the proposal number associated with the issue
they have fixed. OS/400 developers promote their changes to the appropriate QA
environment on the iSeries. If these changes rely on the client-based changes also being
made, the changes are left in the development environment on the iSeries pending receipt
and deployment of the client objects from MKS Source. Once the client objects are deployed
to the OS/400 development environment, all objects are then promoted on a single
Implementer promotion request to the QA environment.
Step Three: Create Release Object for Production (Build)
Two types of desktop development need to be considered here: release-based and continuous.
The following describes released-based development. Continuous development is essentially
the same, except there is no build reference.
The buildmaster updates all proposals associated with the issues addressed by the current
build. That way all the issues can be tied back to the build using a build number (custom field
on a proposal). This build number field can either be entered manually to the proposals in
cases where few issues are involved, or it can be set using the MKS Integrity batch operation
function in larger impact changes.
NOTE In continuous development, the buildmaster uses the Export to Implementer
command to export by issue number.
The buildmaster builds the code that includes the set of issue fixes. The buildmaster also
gathers the source code version information from the change packages attached to the
proposals that address the issues, either using the MKS Integrity Change Package feature or
by manually determining what source items are required based on the level of complexity