⚙    bpm    sdlc    bianl    data    meta    math    ⚙ 👐 🎭 index - references    elucidation    metier 🎭
👐    Intro    Tech (I)    Tech (II)    Initial tasks    Advanced tasks    Results evaluate    👐    top bottom   👐
👐    Release Guide    Release Triangle    Support Tools    RTE ALC type2    RTE ALC type3    Realisations evaluate    👐

relmg DEVOPS = Value stream, removing constraints


Release mangement, Versions of business logic

Making work of ICT colleagues easier.

Chooses for PM fast good cheap, full circle Testautomation in the releasetrain Control testautomation in the releasetrain Control releasetrain Control Data information security Control dataflow Working experiences by some controls. The SIAR cycle is there using the corners 👓, topic cycle in the center.

SIAR:
S Situation
I Initiatives
A Actions
R Realisations

🔰 lost here, than.. devops sdlc.

Progress


Contents

Reference Topic Squad
Intro Making work of ICT colleagues easier. 01.01
Tech (I) Learning the technical environment (I). 02.01
Tech (II) Learning the technical environment (II). 03.01
Initial tasks Initial Tasks release trains. 04.01
Advanced tasks Advanced Tasks release trains. 05.02
Results evaluate Evaluating results - technical. 06.01
Words of thank to my former colleagues 06.02
Release Guide Guidelines releasemanagment. 51.01
Release Triangle Lost in the release management triangle. 52.01
Support Tools Recent versioning tooling - old concepts. 53.01
RTE ALC type2 ALC model-2. 54.01
RTE ALC type3 ALC model-3. 55.01
Realisations evaluate Evaluating realistions. 56.01


sea log

Learning the technical environment (I).


For the processes the limitations of what is technically available at a moment is important. Although the technical situation is not important for the concepts of a design, they are defining the options in realisations.

The era authorisation became part of the technical system.
⚙ Early computer processing In the early day´s of computer processing there was no need for securing resources options. The systeme was operated b operators and no one else did have access. Delivering what was wanted to get processed on pucnh cards.
This changed when end-users got terminals and OLTP systems were introduced. Some of the activities done by operators moved to end-users. This shift in technology was made in in the 80´s.
The first approaches for securing resources was in doing that in:

What really new is although from mid 1980:
The system authorization facility (SAF) provides an installation with centralized control over system security processing through a system service called the MVS™ router. The MVS router provides a focal point for all products that provide resource management. The resource management components and RTE ALC type2 call the MVS router as part of security decision-making functions in their processing, such as access control checking and authorization-related checking. These functions are called “control points”. SAF supports the use of common control points across products and across systems. ...
security central part in the system
The RACROUTE macro invokes the MVS router. When it is invoked, the MVS router first calls an optional installation exit routine and then calls the external security product (such as RACF), if one is active and installed on the system, as shown in the illustration that follows.
In this concept security interfaces and security management got decoupled from doing scripting. The disdavantage is that those interfaces must get implemented in middelware and business applications.

Monitoring logging is not that technical SAF interface. For monitoring and logging writing all events is SMF. SMF is a generic system facility for all kind of RTE ALC type2. Events as a change in the database by an end-user or some resource usage eg over the last 5 minutes. security wiht logging (smf) racf
Source: zsec_admaud_racf_gsg.pdf when Racf is the external security product.

Building a secure environment in the release management context using these concepts is far more easy. Classification of artefact a prerequisite. The most simple implementation is by using naming conventions of the artefacts.

green logl

Learning the technical environment (II).


Monitoring, logging, telemetry is a basic information source. Not knowing what is going on, not knowing when something is done wrong, not able to predict what could happen seeing change in measurements is a business threat.

Client Server - distributed processing.
Using a single system (mainframe) is not state of the art. Using distributed systems, client server, web services is. Application resource monitoring Application response measurement (ARM 1998) , an API jointly developed by an industry partnership, monitors the availability and performance of applications. ARM is an approved standard of The Open Group.
To ensure that requests are performing as expected in a multi-tiered heterogeneous server environment, you must be able to identify requests based on business importance. In addition, you must be able to track the performance of those requests across server and subsystem boundaries, and manage the underlying physical and network resources used to achieve specified performance goals. You can collect this performance data by using versions of middleware that have been instrumented with the Application Response Measurement (ARM) standard. Combining ARM calls within your application with an ARM agent, users of your application can answer questions like:

Some new operarting systems.
A not that well known engineer moving from Dec (Digital Equipment Corporation) Cutler, .., who still comes to his office each day on Microsoft’s sprawling Redmond, Washington, campus, has shaped entire eras: from his work developing the VMS operating system for Digital Equipment Corporation in the late ‘70s, his central role in the development of Windows NT - the basis for all major versions of Windows since 1993 - to his more recent experiences in developing the Microsoft Azure cloud operating system and the hypervisor for Xbox One that allows the console to be more than just for gaming.
What he has done is a complete redesign of an operating system. The concepts are there but using open standards is less obvious. LDAP (AD) is one of the best innovations.

What about Unix - linux? It was developped in the 60´s a complete redesign and opens standards for decoupling authorisations is missing or you could say there are too many of those standards.

Security Management Triangle
At project management the following constraint should be well known. Cost (budget), Time, Scope and resluting quality. One (or more) of those is easliy getting lost.
In security there are also several triangles with constraints that are having a balancing act. Those are far more ignored. security adding to release management
It is very confusing to name middleware software and business logic business data both applications. They are at a very different level of information usage.

modern5 logl

Initial Tasks release trains.


It al started when seeing all the manual work, the long time waiting somebody completed his part of work, the same work being repeated over and over again. That repetition has historical grown because of it was done in several departments not having thoughts on cooperation.

Defining business logical artefacts
When started to do classification for artefacts types. There is:
Not all artefacts are easily eligible to put into a generic releasement tool.
You can put documents in it and test reports and offloaded database records. The check for any difference in source code line will not work.
😉 Doing this defining of SDLC lines of artefacts regular. This is how a release train gets done. When implementing JST, supporting SAS and more having done this over and over again.

Defining types of processess
There are three naming conventions needed for the needed classifications to group them for managing the security..
Often naming conventions are already in place. Changing what is in use is more difficult when it is a new green field. Existing naming conventions are sufficient when the needed grouping is easily done.
😉 Doing this enables the SDLC lines of artefacts. This is how a release train gets done. Without defined logical containers for information at rest (storage locations) and information in transit (being processed) neither the end situation or the development process will be safe.

💣 Stating that every "application" should have his onw dedicate (virtual) machine just is moving the problem wiht the same question in the number of machines. Take a look in the number of servers that are in use. I have seen numbers of 2.000 10.000 and up with the claim that a very limited number of persons (less ten 10) are needed for that. Ask the question for what?

Defining administrator roles
The practical cases: 😱 I never got these conflicts understood by the responsible accountable ones.

modern7 logl

Advanced Tasks release trains.


Naming conventions are realisations of grouping of objects, resources, artefacts with the goal to be able to manage those. It is master data management, MDM, in an localised configuration organisation context. Naming conventions are the fundament for information processing.

naming conventions (transit) for user accounts
🎭 basic user account User account on a mainframe (TSO) did have the limitations of maximum 7 characters. The first character not a number. A seen convention is to use the first 5 characters extracted from the persons name and 2 digits to make the account unique. The 8-th character is reserved for starting a sub process.

⚙ Windows is using a complex sid schema that is translated for human readliblity
⚙ Unix, Linux did also have that kind of restrictions (maximum length 8), some have changed. Unix is using an id-number for users and gid-number for groups that are translated for human readability.
⚙ Websites do not have those kind of limitations. An email-address or telephone number are other options for identification (not authentication) of the user with a naming convention for his personal account.

🎭 high privileged, admin accounts These are also user accounts with some special authorisations for a dedicated task. One type of usage is the promotion - roll back of business logic artefacts in the release train.
An alternative when admin accounts are not getting passed by IAM (Identity Access Management) departments is to use one person activities not be in conflict with the segregations of duties requirement.
⚖ 😉 By restricted admin accounts, security is easy implemented compliant.

naming conventions (transit) for batch processes
🎭 An adhoc batch process is free when associated with a personal account.
🎭 Running a defined business application, than following a naming convention for those recognisable for all environments having relases for it is the wasy to go.

The limit in the mainframe era was set by having a mximum of 8 characters.
⚙ An used naming convention done wiht JST is: ⚖ 😉 By naming convention the security is easy implemented strict compliant.

⚙ An used naming convention done with JST is: ⚖ 😉 By restricted service accounts, security is easy implemented strict compliant. 💣 The issue with restricted service accounts is that: defining maintaining is an organisation responsibility.

naming conventions (transit) for system services
A system service is running services, What else would make sense to use service accounts for those.
The DBMS wiht JST got solved to use the surrogat class to switch the user context into the one of a DTAP segregated service accounts.
Supporting SAS and other recent tools this never went into normal accepted at realisations.
⚖ 😉 By restricted service accounts, security is easy implemented strict compliant. 💣 The issue with restricted service accounts is that: defining maintaining is an organisation responsibility. Not solved by service providers and not by software manufacturers. That wrong assumption is too often made. 😱

naming conventions (at rest) business logic
Just define a technical ownership by a dedicated admin account when access rights are controlled by that dedicated admin account. With this building block all what is needed for a release train bussiness logic is complete
⚖ 😉 By restricted admin accounts, security is easy implemented compliant.

naming conventions (at rest) business data
Just define a technical ownership by a dedicated admin account when access rights are controlled by that dedicated admin account. With this building block all what is needed for doing any run on isolated businessdata is complete
⚖ 😉 By restricted admin accounts, security is easy implemented compliant.

naming conventions (at rest) middelware tools
Just define a technical ownership by a dedicated admin account when access rights are controlled by that dedicated admin account. With this building block all what is needed for installing and running middelware -tools- is complete
⚖ 😉 By restricted admin accounts, security is easy implemented compliant.

😱 I never got understood by the responsible accountable ones why all segregations using dedicated accounts is mandatory by regulations.

lost

Evaluating results - technical.


The are no real technical issue with the challenge of release management. There seems to be a disordered sitatuion in the complicated questions on how to implement an accaptable workable solution. The security model of the intended procution environment is a pre-requisite.

A logical framework for release management (versioning)
A framework for release management used with localisation for the specific situation.
Some generic requirements: Components at rest in a figure:
releasemanagement tools technique
The Develop and Test (integration / system), as similar as possible conform the intended production situation.
💡 Any authorisation model (security) made effective at T conform P.

The System Development Life Cycle using compinents.
A framework for process pipe lines with localisation for the specific situation.
Some generic requirements: Components at transit in a figure:
releasemanagement tools technique The Develop and Test (integration / system), as similar as possible conform the intended production situation.
💡 Any process steps made exactly similar (no changes) at T conform P.

Questions on how to make the development life cycle lean.
💡 Proposed steps in responding, removing constraints:
Not always unhappy by what is going on
Ending bridge
this topic ends here. back to devops sdlc
👓 🔰


Guidelines releasemanagment.



Guidelines eg iec/iso 27002, Relese management
istqb
12.5.1 Installation of software on operational systems istqb
iso 270002 12-5-1b
Those guidelines, mentioned in regulations, are clear. The intention is to know which software version was used on a moment in time in the ⚠ production ❗ environment.

Guidelines Adminsitrator roles
Systems services are processes classified as "high privileged", the security should set with the principle of least privileges ❗
Adminsitrator roles are processes classified as "high privileged", the security should set with the principle of least privileges ❗.
The provider shall design and pre-configure the product according to the least privilege principle, whereby administrative rights are only used when absolutely necessary, sessions are technically separated and all accounts will be manageable. (enisa Indispensable baseline security requirements for the procurement of secure ICT products and services 2016 )


Lost in the release management triangle.


The project triangle at Sofware Development life Cycles
Rte devil triangle
Wanting artefacts deployed, ⬅
💣 forgot the goal at production with the artefacts quality and their impact.

Wanting deployed into production, ⬅
💣 forgetting to have selected verified well functional artefacts.

Wanting at production artefacts, ⬅
💣 forgetting deployment, lifecycle.


Missing the goal of a Sofware Development life Cycles
Words are often not covering the intentions and meaning in the given context. One of the abused ones is "versions".

release management with SAS artifacts is confusing when not knowing how every artifact is behaving. Problematic is that every approach is happening.
Code can be interpreter like, that is there is no source location as the runnable code is the source code.
be generated from a database metadata (5-gl), that implies there is a source database, not source code. Only export/import to containererd objects to promote is doable.

Missing the goal of what artefacts to put in a SDLC
MAchine learning git Assuming you can put a data mining project into git for versioning, will cause big issues.
A data mining project using real easily grows above many Gb's. Have seen them using 60Gb and more.
The sizing limit with version-tools like git is based on 3-gl languages. Detecting differences is based on a 3-gl, manual source getting compiled, assumption.
Bitbucket from Atlassian repository limit (total of all historical versions) of 1 Gb.

logo git
Missing the role of approvements
benevolent-dictator.png The git reference. Used with os shell (xcmd) commands.

Using any releasement tool is always requiring an ulitmate approver, git name: "dictator".

sdlc_gitwrk_01.png Git uses a local repository that copies locally all files in an os-directory structure. These are the daily working actvities. A central repository to be connected. All artifacts are verified on incremental changes, blocking when something is out of order.

Recent versioning tooling - old concepts.


The project triangle at Sofware Development life Cycles
Project managament devil triangle
Wanting artefacts deployed, ⬅
💣 forgot the goal at production with the artefacts quality (not good).

Wanting deployed into production, ⬅
💣 forgetting to have selected verified well functional artefacts (not cheap).

Wanting at production artefacts, ⬅
💣 forgetting deployment (not fast).


Git Generic usage
nvie git lines Nvie is often referred as a succesfull approach using git. The picture at the right is Git nvie.
It shows branching lines features (develop), develop (integration), Release barcnches (acceptance), hotfixes , master (P).
It isn´t showing the release management and archiving.

It doesn´t solve anyting on the requirement for versioning for production environments. It doesn´t solve a complete previous version CMDB information.
Focus: developing software (3gl).

classic modelv2 lines
Classic life cycle model DTAP
The classic approach is having clear stages for relases with their versions and archiving.
The development lines are the same.

The software library is the central location having all possible future, current, and previous versions of production software.

Classic life cycle using more recentnew tools
CA Endevor SCM an example of a complete service doing release management. ca endevor git

Note the flow by lines of the master, parallel development, an emergency fix.
Nothing has really changed. There is a heavily focus on getting some tool. Not seeing the questions what business problems the tool should solve.
The focus on the goal to achieve, release management, is missing.

ALC model-2


⚙ 🎭 SAS Usage ALC type 2

In the basic approach, analysts are needing data, the code they build should run predictable repeatable.
The support is for interactive and operational batch similar, solving the same issues. Accpetable runtime performance is important considering choices.

The following questions solved and implemented:

rls_sascntr_p.jpg
⚙ ⚖ Concatenation, metadata packaging, post deployment
With the surprising big variation in artefacts, every type is possible handled different. Every artefact type having his own technical solution to implement in achieving release management.
💣 Concatenation is very difficult for the ones not used to cooperate but wanting to have all on a personal location.
⚠ SAS is using "Applications" without the mandatory logic and data segregation in their "Server configuration"

A limited list of artefact handling:
Artefact description release approach
base code Embedded Eguide. Requiring to store in an external source repository.
base code Concatenation is the most appropriate approach.
macro function Interactive compiled, same approach as base SAS code.
formats Interactive compiled, same approach as base SAS code.
compiled function Interactive compiled, same approach as base SAS code.
SCL SAS catalogs using concatenation.
user-calendar base sas code creating datasets.
Data Integration Metadata, package & unpack sas code.
Miner project OS:directories, metadata references.
Miner metaobject Metadata result package & unpack into metadata.
LSF jobs (repo) Metadata. Redefine repositories for target SAS code once
LSF jobs (flows) Metadata &and LSF DBMS. Metadata package & unpack into LSF.


ALC model-3


⚙ 🎭 SAS Usage ALC type 3
What is done for mdl2 being extended to what the Application Life Cycle, Analytics Life Cycle, is needing.
The support is for interactive and operational batch similar, solving the same issues.

The following questions solved and implemented:

rls_sascntr_a.jpg
⚙ ⚖ Big variation in SAS artifact types
The variaton in artifacts is surprising big, every type being used to manage in release management. Every artifact type having his own technical solution to implement in achieving release management.

A list (limited) of artifacts:
Artifact description source location config runnable
base code Embedded Eguide export OS: <name>.sas
base code -na- -na- OS: <name>.sas
macro function -na- macro-search OS: <name>.sas
formats OS: <name>.sas format-search OS: <name>.sas7bcat
compiled function OS: <name>.sas fcmp-search OS: <name>.sas7bitm
SCL SAS catalog compile scl OS: <name>.sas7bcat
user-calendar OS: <name>.sas calendar-set OS: <name>.sas7bdat
Data Integration Metadata compile generate OS: <name>.sas7bdat
Data Integration Metadata export-import Metadata
Miner project OS:directories -na- Metadata
Miner metaobject Metadata -na- OS: <name>.sas
LSF jobs (repo) Metadata job deploy OS: <name>.sas
LSF jobs (flows) Metadata export-import Metadata
LSF jobs (flows) Metadata -lsf Manual modify- LSF repository
... ... ... ...


⚙ 🎭 Generic ALC type 3 Usage
Before going to work dedicated with the SAS tooling I did the "system programmers" role using a lot of tools. Still doing a lot of tools when opening up what is behind delivered technology and adjusting that for a better fit.
The support and implementation of JST was a good fundament for seeing the business processes. The good experiences to reuse over and over again.

pioneering

Evaluating realistions.


Any conclusion from experiences is that no one will be happy wiht any situation. In the devops sprint goal, releasing artefacts in the end of any sprint is a deadline with frustrations.

CI / CD Continuous Integratation Continous Delivery
CI / CD a goal where the business goal is not mentioned. What is the idea?

CI and CD are two acronyms that are often mentioned when people talk about modern development practices. CI is straightforward and stands for continuous integration, a practice that focuses on making preparing a release easier. But CD can either mean continuous delivery or continuous deployment, and while those two practices have a lot in common, they also have a significant difference that can have critical consequences for a business. Atlassian Sten Pittet
CI CD atlassian bitbucket
Developers practicing continuous integration merge their changes back to the main branch as often as possible. The developer´s changes are validated by creating a build and running automated tests against the build. By doing so, you avoid the integration hell that usually happens when people wait for release day to merge their changes into the release branch.
Continuous integration puts a great emphasis on testing automation to check that the application is not broken whenever new commits are integrated into the main branch.

Continuous delivery is an extension of continuous integration to make sure that you can release new changes to your customers quickly in a sustainable way. This means that on top of having automated your testing, you also have automated your release process and you can deploy your application at any point of time by clicking on a button.
Why is the business not involved in acceptance and should wait to see it when has deployed into production? Many business applications have a release date for business reasons. Just adding some products in a shop should not done by changing logic but by changing business data.

Release mangement is a frustrating topic
Release management (at rest), process pipe lines (in transit), is suffering from just focussing on two of the three important aspects.
⚠ Versioning, deploing releases, should be fast good and cheap, choose two.
⚠ Managing processes (production), should be fast good and cheap, choose two.
⚠ Artefacts servicing business, should be fast good and cheap, choose two.
⚠ managing component at rest (software versions), managing process pipe lines (in transit), servicing customers should be fast good and cheap, choose two.

Release triangle 2 out of 3, full circle Data information security Control testautomation in the releasetrain Control releasetrain Control Data information security Control dataflow Working experiences by some controls. The SIAR cycle is there using the corners 👓, topic cycle in the center.

SIAR:
S Situation
I Initiatives
A Actions
R Realisations

🔰 lost here, than.. devops sdlc.


👐    Release Guide    Release Triangle    Support Tools    RTE ALC type2    RTE ALC type3    Realisations evaluate    👐
👐    Intro    Tech (I)    Tech (II)    Initial tasks    Advanced tasks    Results evaluate    👐    top bottom   👐
⚙    bpm    sdlc    bianl    data    meta    math    ⚙ 👐 🎭 index - references    elucidation    metier 🎭

© 2012,2020 J.A.Karman