JAL: add graphics

2015-10-27T23:06:09Z

add graphics

Admin: 1 revision

2015-10-19T21:37:24Z

1 revision

← Older revision	Revision as of 21:37, 19 October 2015
(No difference)

JAL at 22:53, 16 October 2015

2015-10-16T22:53:12Z

New page

Manipulating update procedures instead of whole procedure files offers
a large number of advantages in managing the <var class="product">Model 204</var> environment.
These advantages are seen in simplified and more flexible pathing
schemes for promoting changes, clearer accountability for change, and a
more powerful and direct way of building a bug-free production system.

The flexibility of <var class="product">SirLib</var> allows sites to use the product in a number
of different ways.
The best <var class="product">SirLib</var> implementation is the simplest one that handles all the
complexities of a site's application needs.
Factors to consider include:
<ul>
<li>The number of regions available for developing, testing, maintaining
and running production <var class="product">Model 204</var> systems. </li>

<li>The relative volume of new development vs. maintenance activity. </li>

<li>The complexity and length of application testing. </li>

<li>Local coding standards. </li>
</ul>

In general, sites want to accomplish as much as possible in each
available Online region.
Therefore, functional areas tend to be merged whenever possible: either
development and testing or development and maintenance are run in a single
region, with some shops having the luxury of a unique region for each
functional area, and other shops having to develop and test, run and
maintain production all in a single region.
<var class="product">SirLib</var> can accommodate any of these situations, but here a kind of optimal situation is discussed, where functional areas are merged
into a single region whenever it is possible without causing programmers,
testers, and users to interfere with each other.

A practical limit with <var class="product">Model 204</var> makes it difficult to merge more than two functional areas into a single region.
Assuming that a shop is taking advantage of the Application Subsystem
(APSY) feature of <var class="product">Model 204</var>, and that there are embedded references to
procedure files in the SOUL code (for example, statements like
<code>IN PROCFILE INCLUDE xxxxxx</code>), only two versions of any
application subsystem can be run in the region — one with the specified
procedure file, and a second whose APSY definition has a procedure group
defined with the same name.

If a site wants to run three versions of a subsystem in a region, say a
development APSY, a test APSY, and a copy of the production APSY,
programmers have to do one of the following:
<ul>
<li>Change procedure references when moving
procedures between subsystems </li>

<li>Code in such a way that no procedure file references are used </li>

<li>Dynamically free and allocate files </li>

<li>Change the definition of the procedure group used by one of the APSYs </li>
</ul>

A site might also code all procedure file references with dummy string
substitution or, as mentioned above, not use the Application Subsystem
feature.
Any of these options sacrifices some of the strengths of <var class="product">Model 204</var> or places
unnecessary restrictions on coding staff.

==Configuration examples==
Given that no more than two functional areas should operate within a
region, and assuming a shop requires a full-scale testing environment,
the following example shows one possible implementation of change
management using <var class="product">SirLib</var>.

:FIGCAP.Managing changes across 3 environments, using SirLib in each

The problem with the above example is that any volume of maintenance
fixes will interfere with the normal course of development.
With testing given its own online region, programmers will have to balance
scheduled development with production fixes.
Development may have to be set aside (by temporarily renaming procedures
being worked on, for instance) while emergency fixes are coded, then the
fixes will have to be incorporated with the new development work quickly,
as the region is turned back over to development tasks.
If fixes to production are a regular occurence this can be an expensive
and time-wasting way to work.

If a site wants to eliminate the complexity of dealing with update
procedures in every region, the previous flow of change could be
simplified to look like this:

 ID=libr10 :FIGCAP.Managing changes across three environments, using one copy of SirLib

Again, this configuration has the same problems with emergency fixes
and other unscheduled maintenance interfering with the development
schedule, and the ensuing complications in the development environment.
In addition, while you gain the simplicity of only dealing with update
procedures in the development region, you lose some of the strengths of
<var class="product">SirLib</var>: the ability to verify and reconfigure the state of procedure files in any region and the simplified distribution provided by the FixFile.

In addition, under this scheme, testers need to be given the
entire test file over again every time changes are requested of the
development team, and of course, the entire procedure file must be sent
to production each time a release is made.

A final example of a <var class="product">SirLib</var> configuration is the way that Sirius Software used the product for its own development and maintenance
distribution.

Because the Sirius "production" environment was a large number of
client sites, and the amount of maintenance required on a
release was unpredicatable, Sirius used a single environment for development
and testing, and it reserved a second environment for ongoing maintenance
on each production release.
This configuration allowed the building of new
releases in the same Online region where complex testing occurred, and allowed the simultaneously reconfiguring of the maintenance environment to match that
of any client experiencing problems.
An example of this setup is shown below:

ID=libr11 :FIGCAP.Separately managed development/unit testing and release testing

The "next" release of an application was developed in the
Development/Testing region, using <var class="product">SirLib</var> to manage the staging of completed units.

This is an excellent option for anyone with a large volume of
development work in progress, complex testing requirements, and
production environments that may require unsheduled programming not
easily integrated with ongoing new development.

==See also==
{{Template: SirLib topic list}}

[[Category: SirLib]]

SirLib configuration options - Revision history

JAL: add graphics

Admin: 1 revision

JAL at 22:53, 16 October 2015