SirLib configuration options: Difference between revisions

From m204wiki
Jump to navigation Jump to search
mNo edit summary
 
m (add graphics)
 
(One intermediate revision by one other user not shown)
Line 4: Line 4:
<!-- Page name: SirLib configuration options-->
<!-- Page name: SirLib configuration options-->
Manipulating update procedures instead of whole procedure files offers
Manipulating update procedures instead of whole procedure files offers
a large number of advantages in managing the <var class="product">Model 204</var> environment.
a large number of advantages in managing the <var class="product">Model&nbsp;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.
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
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.
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:
Factors to consider include:
<ul>
<ul>
<li>The number of regions available for developing, testing, maintaining
<li>The number of regions available for developing, testing, maintaining,
and running production <var class="product">Model 204</var> systems. </li>
and running production <var class="product">Model&nbsp;204</var> systems. </li>


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


<li>The complexity and length of application testing. </li>
<li>The complexity and length of application testing. </li>
Line 26: Line 20:


In general, sites want to accomplish as much as possible in each
In general, sites want to accomplish as much as possible in each
available Online region.
available Online region. Therefore, functional areas tend to be merged whenever possible: either
Therefore, functional areas tend to be merged whenever possible: either
development and testing, or development and maintenance are run in a single region. Some sites have the luxury of a unique region for each functional area, and others have to develop and test, run and
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.
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.
<var class="product">SirLib</var> can accommodate any of these situations, but this page discusses a kind of optimal situation 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&nbsp;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
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
(APSY) feature of <var class="product">Model&nbsp;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 &mdash; one with the specified procedure file, and a second whose APSY definition has a procedure group defined with the same name.
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 &mdash; 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
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,
development subsystem, a test subsystem, and a copy of the production subsystem, programmers have to do one of the following:
programmers have to do one of the following:
<ul>
<ul>
<li>Change procedure references when moving
<li>Change procedure references when moving procedures between subsystems </li>
procedures between subsystems </li>


<li>Code in such a way that no procedure file references are used </li>
<li>Code in such a way that no procedure file references are used </li>
Line 56: Line 39:
<li>Dynamically free and allocate files </li>
<li>Dynamically free and allocate files </li>


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


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


==Configuration examples==
==Configuration examples==
Line 69: Line 50:
region, and assuming a shop requires a full-scale testing environment,
region, and assuming a shop requires a full-scale testing environment,
the following example shows one possible implementation of change
the following example shows one possible implementation of change
management using <var class="product">SirLib</var>.
management using <var class="product">SirLib</var>:


<p class="code">:FIGCAP.Managing changes across 3 environments, using SirLib in each</p>
<p class="caption" style="width:450px">Managing changes across three environments, using SirLib in each</p>
<p class="figure">[[File:SlibMng3Environments.png|450px]]</p>


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


Line 88: Line 68:
simplified to look like this:
simplified to look like this:


<b> ID=libr10</b> :FIGCAP.Managing changes across three environments, using one copy of SirLib</p>
<p class="caption" style="width:450px">Managing changes across three environments, using one copy of SirLib</p>
<p class="figure">[[File:SlibMng3Environments1Sir.png|450px]]</p>


Again, this configuration has the same problems with emergency fixes
Again, this configuration has the same problems with emergency fixes
Line 95: Line 76:
In addition, while you gain the simplicity of only dealing with update
In addition, while you gain the simplicity of only dealing with update
procedures in the development region, you lose some of the strengths of
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.
<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.
<p>
<p>
In addition, under this scheme, testers need to be given the
In addition, under this scheme, testers need to be given the
entire test file over again every time changes are requested of the
entire test file again every time changes are requested of the
development team, and of course, the entire procedure file must be sent
development team. And of course, the entire procedure file must be sent
to production each time a release is made.</p>
to production each time a release is made.</p>


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
A final example of a <var class="product">SirLib</var> configuration is the way that one company used the product for its own development and maintenance distribution. Because the company "production" environment was a large number of client sites, and the amount of maintenance required on a release was unpredicatable, the company used a single environment for development and testing, and it reserved a second environment for ongoing maintenance on each production release.
distribution.


Because the Sirius "production" environment was a large number of
This configuration allowed the building of new releases in the same Online region where complex testing occurred, and it allowed the simultaneous reconfiguring of the maintenance environment to match that
client sites, and the amount of maintenance required on a
of the client experiencing problems. An example of this setup is shown below:
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:


<p><b>ID=libr11</b> :FIGCAP.Separately managed development/unit testing and release testing</p>
<p class="caption" style="width:450px">Separately managed development/unit testing and release testing</p>
<p class="figure">[[File:SlibMngEnvSep.png|450px]]</p>


The "next" release of an application was developed in the
The "next" release of an application was developed in the

Latest revision as of 23:06, 27 October 2015

Manipulating update procedures instead of whole procedure files offers a large number of advantages in managing the Model 204 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 SirLib allows sites to use the product in a number of different ways. The best SirLib implementation is the simplest one that handles all the complexities of a site's application needs. Factors to consider include:

  • The number of regions available for developing, testing, maintaining, and running production Model 204 systems.
  • The relative volume of new development versus maintenance activity.
  • The complexity and length of application testing.
  • Local coding standards.

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. Some sites have the luxury of a unique region for each functional area, and others have to develop and test, run and maintain production all in a single region.

SirLib can accommodate any of these situations, but this page discusses a kind of optimal situation 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 Model 204 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 Model 204, and that there are embedded references to procedure files in the SOUL code (for example, statements like IN PROCFILE INCLUDE xxxxxx), 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 subsystem, a test subsystem, and a copy of the production subsystem, programmers have to do one of the following:

  • Change procedure references when moving procedures between subsystems
  • Code in such a way that no procedure file references are used
  • Dynamically free and allocate files
  • Change the definition of the procedure group used by one of the subsystems

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 Model 204, or it 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 SirLib:

Managing changes across three environments, using SirLib in each

The problem with the above example is that any volume of maintenance fixes 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 occurrence, 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:

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 SirLib: 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 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 SirLib configuration is the way that one company used the product for its own development and maintenance distribution. Because the company "production" environment was a large number of client sites, and the amount of maintenance required on a release was unpredicatable, the company 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 it allowed the simultaneous reconfiguring of the maintenance environment to match that of the client experiencing problems. An example of this setup is shown below:

Separately managed development/unit testing and release testing

The "next" release of an application was developed in the Development/Testing region, using SirLib 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