App Builderconcepts

8/14/2019 App Builderconcepts

1/46

BluePhoenix Nebula 2.1

Product Concepts Guide
http://www.bluephoenixsolutions.com/


2/46

BluePhoenix Nebula 2.1Product Concepts GuideOctober, 2005

Corporate Headquarters

BluePhoenix Solutions

The NetherlandsStartbaan 5 B1185 XP, Amstelveen

+31 20 453 2107+31 20 345 5030 fax

USA Headquarters

BluePhoenix Solutions USA, Inc.8000 Regency Parkway

Cary, NC 27511United States

+1 919.380.5100

+1 919.380.5111 fax

www.bluephoenixsolutions.com

2005 BluePhoenix Solutions

All rights reserved.

Nebula and BluePhoenix are trademarks of BluePhoenix Solutions. All other product and companynames mentioned herein are for identification purposes only and are the property of, and may be

trademarks of, their respective owners.

The software supplied with this document is the property of BluePhoenix Solutions, and is furnishedunder a license agreement. Neither the software nor this document may be copied or transferred by anymeans, electronic or mechanical, except as provided in the licensing agreement.

BluePhoenix Solutions has made every effort to ensure that the information contained in this documentis accurate; however, there are no representations or warranties regarding this information, including

warranties of merchantability or fitness for a particular purpose. BluePhoenix Solutions assumes noresponsibility for errors or omissions that may occur in this document. The information in this

document is subject to change without prior notice and does not represent a commitment byBluePhoenix Solutions or its representatives.
http://www.bluephoenixsolutions.com/http://www.bluephoenixsolutions.com/


3/46

Nebula 2.1 Product Concepts Guide i

TABLE OF

CONTENTS Table of Contents

Nebula 2.1 Product Concepts Guide

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Lifecycle Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Build Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2Visibility and Versioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Delivery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Nebula in the Development Lifecycle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Lifecycle Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Enhancement Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6Development Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Items. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Moving through the development process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Change Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Role Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Visibility and Versioning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Datastore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Workspaces and Contexts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Visibility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Release Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Forward Fit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Build Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Delivery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Enabler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

AppBuilder. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4 Customizing Integrated Builds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Build Profile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Build Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32


4/46

ii

5 Customizing Delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Delivery Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Delivery Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41


5/46

Nebula 2.1 Product Concepts Guide 1

CHAPTER

1

INTRODUCTION


BluePhoenix Nebula is a complete application lifecycle and configuration management system that

helps you to manage all the artifacts of your application throughout the development lifecycle. It iscomposed of an object-based change management system, a build management system, and release-

lifecycle configuration management system. Nebula provides greater control, consistent quality, and aconsistent process throughout your application development process. The system is based on an

application development workflow methodology and enforces best practices throughout the lifecycleprocess from the development stage on through stages of Integration, QA, and eventual delivery into

production systems. Nebula is built upon an open and scalable object repository with full versioningcapabilities which enables you to manage all components of your application throughout thedevelopment process. It can also automate and control the build and release packaging of your

application. Nebula is unique in its ability to integrate fully with AppBuilder and its model-drivendevelopment architecture.

Features

BluePhoenix Nebula is an open and extensible object repository. In addition to storing AppBuilder-

related objects, Nebula is capable of storing any kind of document, diagram, or program code used by

any language or tool on the market.

Lifecycle Management

Nebula includes a lifecycle management system that is designed to control not just green-fieldapplication development, but also ongoing maintenance, enhancement, and support activity. Each

change to the application follows a carefully-established methodology. Developers can promote changesfrom the development stage into integration, while testers promote the changes through QA and

delivery into final production.

All changes in the lifecycle of an application are initiated by and based upon Enhancement Requests,which can then be broken down into smaller units (Development Tasks, Items). Nebula tracks theprogress of all changes as they progress from development through testing to production.

Roles, such as developer, tester, release coordinator, and others, must be assigned to those working on an

application in Nebula. Roles can be modified project by project and role privileges can be customized.Nebula handles both authorization and authentication of roles.


6/46

2 Introduction

Features

Change management involves the tracking and reporting of all modifications to any part of adevelopment project during the development lifecycle. Nebula can integrate with an external changemanagement or bug-tracking system. Whether Enhancement Requests are generated automatically from

an external system or are generated internally without any external interaction, once Nebula receives anew Enhancement Request, it provides absolute control of the state of the Enhancement Requests and

their subunits, development tasks and items. Every change of state for every Enhancement Request is

tracked. In addition, Nebula tracks and breaks down work for each individual involved in theapplication lifecycle, including developers, testers, release management, and others.

Impact analysis is always based upon object type. Impact analysis can be customized to show whichever

direction you wish, but by default is set to the parent direction in the repository. In addition, fixes madeto one release can easily be integrated directly into a subsequent release.

Build Management

The build management system integrated in Nebula can compile and deliver not only AppBuilderapplications but applications written in any language. From a single Nebula workbench you can build

and deliver applications on a variety of platforms.

Nebula includes one or more build servers. For any particular release, you only build oncea significant

savings in terms of CPU.

The Nebula build profile allows you to specify what objects are to be included for a build, how they areto be compiled and packed on the target platform, other files or services required, etc. The builds are

completely transparent to users and can be set to one or several platforms.

Visibility and Versioning

The concept of visibilityrefers to the ability to see from any particular workspace (such as developmentor QA) within the workspace hierarchy up to view the contents of higher workspaces. In addition,Nebula can create and manage multiple versions (branching, etc.) in the development process.

Nebula establishes a system of contextsand workspacesfor each release. Releases themselves arecompletely separate, with independent runtime environments. Within each datastore, Nebula uses the

concept of promotion, to move objects from one context (development) to succeeding ones (QA,Production). The promotion of objects within the repository through a hierarchical system is more

efficient than copying objects from one context to another.

Delivery

For each release, Nebula includes a delivery profile, specified separately for each system. Each deliverycan be a full package, a delta, or a delta since the last delivery to a customer. The profile also includes the

specifications of which items to be included, how they should be packaged, where they should be placed,and how they are to be deployed.


7/46

Features


Integration

Nebula has a number of ways to integrate with other tools. This includes simple invocation of otherprograms. Nebula has a property list describing relationships between programs and file extensions. Its

easy to add new entries making it possible to invoke new programs. There is also a file-based import/export capability. Nebula can read files in a directory and import/export to/from a given directory. The

file types are defined as properties. Nebula can be customised to handle any file type needed. Nebulasupports a callable import/export with AppBuilder. Other IDEs can be integrated the same way if theyprovide an API. The current implementation of callable import / export from AppBuilder depends

completely on AppBuilders built-in unit-of-work concept. AppBuilder tracks all changes in a tablecalled unit of work. Nebula then uses this table to determine which items to import, and it updates the

table on exports. This is only possible due to AppBuilders API. A similar API can be implemented inorder to extende import / export to other IDEs.


8/46

4 Introduction

Features


9/46


CHAPTER

2

NEBULA IN THE DEVELOPMENT

LIFECYCLE


With Nebula, the development process is driven and controlled by an established and consistent

methodology. Every software engineer has witnessed the problem where the introduction of newfeatures caused some breakage in the existing functionality of the production release. Most commonly,

the cause of such breakage is that a program change was introduced into the production build before itwas properly tested.

To guard against this problem, mature development organizations follow a Development Lifecycle

methodology when developing a new application, introducing new features, or correcting defectsdiscovered in an application. The most common methodology is to separate the work into threeprogressive and hierarchical stages:

Development Stage. In the development stage, programming tasks are completed by engineers,unit tested, and checked into the repository.

Verification Stage. In the verification stage, the changes are built into a test package that is

subjected to verification tests to prove that the changes function correctly and do not break existingfeatures.

Production Stage. In the final production stage, the change is accepted into the application and isactively used by the customers of the system.

It is not sufficient merely to document the development workflow; its use must be enforced. So long asthe source code repository permits an untrained or misguided engineer to subvert the workflow by

bypassing a step, the same problems will appear from time to time, even in a mature developmentorganization. These problems can be avoided when the source code repository forces all work to

progress through a strict development lifecycle.


Nebula's lifecycle management feature explicitly tracks and controls the stage in which a piece of workresides, to prevent untested features from reaching the production stage.


10/46

6 Nebula in the Development Lifecycle


Enhancement Request

In development environments where a large number of development tasks proceed in parallel, finding

an appropriate time to orchestrate a production build can be a difficult proposition. Development tasksare often being started and completed at different times, and a number of tasks may be in progress whena production build is scheduled to occur. One way of solving this problem is to create a rigid process and

notify the development staff that all changes must be completed and checked in at a certain date andtime so that a test or production build might be performed. This solution requires good synchronization

and often creates organizational problems, because it results in unproductive downtime for thedevelopment staff. At its worst, it can result in backing out changes to the system in order to get the

repository to the state where the build can properly occur.

Nebula manages the complexity inherent in large-scale development by imposing a development

lifecycle on the individual units of work, allowing them to progress independently through thedevelopment lifecycle until they are deemed ready to enter the production stage. Further, with Nebula,

you build and unit test in the development (work) context. The same build is system tested in QA and,when approved, moved up to production. There are not separate builds at each stage of work.

Nebula manages all changes as parts of an Enhancement Request(ER). An Enhancement Request is a

logical amendment to the system that is tied to a specific request to change the application, such as achange ticket, engineering request, a recorded defect, or a new requirement. These change requests areusually stored in an external system, and Nebula associates the external system's own identifier with an

Enhancement Request. When a Nebula Enhancement Request progresses through the lifecycle, Nebulaperforms customizable Change Management Integration by notifying the external defect tracking

system of any status changes.

Figure 2-1 Nebula Development Lifecycle

Note For more information on integrating Nebula with external defect tracking systems (such as Customer Firstor Bugzilla) or collaboration and messaging applications (such as Lotus Notes), see BluePhoenix Product

Support.


11/46



The development process moves changed components within a specified version and release from adevelopment (work) context through integration and QA testing to a production context. A SystemAdministrator reviews the Enhancement Requests, breaks them into digestible Development Tasks and

assigns those tasks to developers. A developer identifies which components must be worked on andassociates the components with his assigned Development Task.

Figu re 2-2 Process Flow

Nebula provides a process whereby each Enhancement Request for a designated release is trackedthroughout its stages of development. Those stages of development progress from creation/versioning

through developing, testing and finally to deployment. These states in the lifecycle process are illustrated

in the following figure:

Figure 2-3 Enhancement Request Lifecycle

When Nebula deploys for the various stages of the lifecycle, it only includes those EnhancementRequests that have been promoted to the stage.


12/46



Development Tasks

At times an Enhancement Request is too large for a single engineer, especially in the case where complexnew features are being implemented. To better handle large enterprise teams, Nebula breaks down

Enhancement Requests into one or more Development Tasks, which are then assigned to engineers.

When a Development Task is assigned, an engineer identifiesItems, development artifacts such asAppBuilder objects, bitmaps, documents, and source code that should be modified as part of theDevelopment Task. The engineer makes the appropriate changes, checking in new versions of the Items,

and adding those Items to the Development Task.

Figure 2-4 Enhancement Request and its children

When an engineer changes an Item as part of a Development Task, there may be a large number ofdependent Items that must be identified and changed before a successful build can take place. Nebulauses its Impact Analysis capability to determine which dependent Items are affected by the change.

Nebula captures dependency relationships in the repository model so that impact analysis can happenindependently of the build procedure.

Figure 2-4illustrates how each Enhancement Request can be conceived as a hierarchy, with a name for

the Enhancement Request at the top level, identified Development Tasks beneath that, and specific Itemsat the lowest level. The Items may be particular files or file types (COBOL files, copybooks, executables,Java files, etc.), for example. Each Enhancement Request may have one or more Development Tasks;

each Development Task controls one or more Items and affects one or more Items.

Nebula tracks whether one Item controls others and whether it affects others automatically as the

Enhancement Request moves through the lifecycle process.

Items

Each Development Task can include one or more Items(files, AppBuilder rules, libraries, windows, etc.)associated with it and necessary for solving the task. The assigned engineer has full control over theItems attached to assigned Development Tasks. In addition, an engineer can create new Items, such as

listing new required files, and add them to a Development Task.


13/46



Moving through the development process

Each Enhancement Request and its children (Development Tasks and Items) begin in the state Started.

The overall Enhancement Request begins in the work context for the designated release.

Figure 2-5 ER in stage Star ted

Each developer assigned to a Development Task has full control over the Items attached to that task. The

developer can create and add new Items to each task. As a task or Item is completed, the developer canmark it as ready for integration.

Note In these illustrations of the lifecycle process, Enhancement Requests are represented by a triangle,Development Tasks by a square, and Items by a circle.


14/46



Figure 2-6 Items ready for integrat ion

When a developer has completed more Items and tasks, they too can then be moved to the ready forintegration state. The parent Enhancement Request is still in the Work context and new tasks can still

be added.

Figure 2-7 Task ready for integrat ion

When the Items attached to a task are unit tested, the developer marks this on the Development Task.When a developer has ended his work (and unit tested it) he checks in the work and moves the task andall its Items to the stage ready for integration. This makes the Items accessible to other developers.


15/46



When the Enhancement Request is complete, the engineer moves it into the state ready for integrationand it is integrated with other Enhancement Requests (that may share the same Items). At this stage, theEnhancement Request is complete and no new tasks can be added to it.

Figure 2-8 Enhancement Request in integrat ion

A developer can move the Enhancement Request and all its children from the state ready forintegration to ready for test. A tester then can then take control of the Enhancement Request. The

Items, Development Tasks, and Enhancement Request can move ahead, as Approved to In test. Ifindividual Development Tasks or Items pass testing, but the entire Enhancement Request does not, it

can be marked as Partly Approved while issues are resolved.

Figure 2-9 Enhancement Request moving in Test context


16/46



Once the Enhancement Request and all its children (tasks, Items) pass testing, a tester can move theItems from the state In test to the state test approved. From there, a release manager can move theobjects into the Production context and the Enhancement Requests can be prepared for release.

Figure 2-10 Enhancement Request moving into Production

Change Management

Change managementrefers to the tracking of all modifications to data within the repository. Nebulaprovides change tracking and can be integrated with other defect-tracking or test-management systems.

It is possible to generate an entry through a third-party defect-tracking or test-management systemintegrated with Nebula. Regardless of which change management system you are using, the entry is

given a unique identifier and then sent to Nebula as an Enhancement Request. The newly-createdEnhancement Request becomes part of the Enhancement Request pool, and can then be assigned to aparticular release and developer.


17/46



Figure 2-11 Change management

Because Nebula provides full integration with other systems (defect-tracking, test management, etc.),

the progress of Enhancement Requests through the development process can be tracked and notices canbe sent about the status of the progress.

Figure 2-12 Change management, continued

Nebula has an open API for providing status updates to any external change management system.Therefore, Nebula can be integrated with almost any other change management system or defect-

tracking system.


18/46



Role Management

In the lifecycle management process, source code modifications may only be promoted to the next stage

by an employee who is authorized to make the decision. Nebula defines certain Rolesto empower certainemployees to promote an Enhancement Request from one stage to another. These roles are fundamentalin application development, including developers, testers, release managers, and others.

Figure 2-13 Roles and authorization in the lifecycle process

For example, a developer role can promote an Enhancement Request to the Integration stage whencoding and unit testing is complete, but a developer does not have the authorization to promote the

Enhancement Request into Test or Production. An Enhancement Request must be promoted throughTest by a person in the QA role. Nebula enforces lifecycle progression to improve the quality of theapplication.


Nebula utilizes Fujitsu Enabler as a repository and uses its data model. Because of this, Nebula uses a

number of terms in specific senses so as to be consistent with Enabler and its documentation. Theseterms include datastore, workspace, context, and visibility.


19/46



Datastore

Data is stored in Nebula in object-based datastores. The elements in a datastore and theirinterrelationships serve as a metamodel. This metamodel represents elements on both the data model

and instance level. That is, the data model describes which instances can exist in a datastore. For eachelement on the instance level, there must be a corresponding data model element.

An Enabler datastore has one single, uniform data model that applies to all workspaces. The data modelincludes object classes. Object classes are a means of classifying objects with common properties. You can

define attributes, relations, and other properties for an object class, and these definitions determinewhich attribute values, relationships, and properties the objects in the class may have.

An object class type determines the purpose for which the objects in the class may be used. Enabler

works with the following types of object class:

Object

Configuration

Workspace

Context

Workspaces and Contexts

The workspace structure of a datastore establishes the framework for storing the datastore instances. Italso influences the visibility and accessibility of the instances. Nebula uses workspacesto model the

development cycle for objects. That is, the datastore contains a hierarchical set of workspaces based onthe stages of a development cycle (development, testing, and production). In this vertical hierarchy, eachworkspace provides a view of the workspaces above it in the hierarchy. Data therefore becomes more

public the higher it is in a workspace hierarchy.

The contextdetermines how data is stored for a given user or application and what view the user or

application has of the data. The context sets the context workspace and determines whetherconfigurations are used. If configurations are used, it is also possible to set a working configuration.


20/46



Figure 2-14 Workspace hierarchy

Nebula uses a promotion model of moving Items from a lower workspace (such as Development) to a

higher workspace (QA and then Staging). In Figure 2-14, while the Staging workspace has an applicationwith multiple objects in it, and the Development workspace contains newer versions of two rules.

In Figure 2-15, the new version of the rules has been promoted to the QA workspace and is ready for

integration.

Tip New versions of objects, whether rules, files, programs, or entire applications can always be created. Nomatter which workspace context the object is currently in, the (new) copy begins in the Development or

Work context. No matter what changes are made to i t, the new version must be moved through the same

stages as all other objects.


21/46



Figure 2-15 Promotion of objects

A developer can create a third version of rule R1 in the Development workspace.

Figure 2-16 Continued development


22/46



The testers working in the QA workspace can move rules R1, V2 and R2, V2 along to the In integrationstage.

Figure 2-17 Promoting versions

Subsequent versions, such as rule R1, V3, follow the same process through these stages.

Figure 2-18 Promoting versions

Finally, as shown in the following figure, the new versions of R1 and R2 are integrated into theapplication.


23/46



Figure 2-19 New versions in staging

Visibility

Because the workspaces are operating as a hierarchy, the visibilityof objects operates upwards. Thus, adeveloper working on Rule 1 in the Development workspace can see previous versions of Rule 1 in the

QA and Staging workspaces above Development.


24/46



Figure 2-20 Visibility from Development workspace

The concept of visibility of versions of objects only works upwards in this hierarchy of workspaces. Thus,

for example, Figure 2-21illustrates the visibility from QA.

Figure 2-21 Visibil ity from QA

Notice that those people working in the testing context cannot see R1, V2.


25/46



Release Configuration

Nebula can version parts of an application or the whole application. This makes parallel developmentpossible. Each release includes 5 contexts:

Figure 2-22 Release contexts

Whether a release includes minor fixes or major changes, each release is conceptually separate from oneanother. A new release is defined and described in Nebula with a release configuration. The release

administrator specifies the properties for the release, including its designation, its baseline, and whetherto create a new runtime for it. Each release has a configurable set of properties in a profile.

Forward Fit

Changes and fixes made to one release can easily be integrated directly into another release. For example,

the changes made in Release A can be moved directly to the Work context of Release B.

Table 2-1 Release contexts

Context name Description

Hot Urgent changes made directly to the current release

Production All items that are ready for delivery

Test Items currently in testing

Integration Integrating new items

Work All items in development


26/46


Build Management

Figure 2-23 Forward Fi t

As a result, Nebula provides a convenient methodology for utilizing parallel development.

Build Management

You must define buildsand releasesin Nebula. As a result, whenever you build an application, you

specify in Nebula what is required, and then Nebula collects all pertinent data from the repository,compiles it on the target platform, and packages it with any other pertinent applications.

Figure 2-24 Bui ld concept

The build management process ensures that the developer or tester doesnt have to know where it will be

installed or how. The build process is always the same seen from a users point of view. Further, once thebuild has been installed into the Test workspace, an uninstall is performed in the Work workspace,

unless a new version exists there.


27/46

Build Management


Figure 2-25 Build management

The build management includes:

build server

build files

build profile

build runtime properties

build script

build results

You can run build servers remotely on Windows, UNIX, and z/OS platforms. All build servers have thefollowing characteristics. They:

Are scalable.

Can be defined per release or reused between releases.

Have a physical Java RMI name or TCP/IP name for the host.

Have a namespace. A physical server can have more than one namespace.

Are self-contained except for bindfile generation; that is, everything is built on build servers.

Can define the maximum concurrent builds.


28/46


Build Management

Figure 2-26 Bui ld servers

A build profileis the container for all defined build scripts. It is release dependent; different behaviors perrelease can be defined. The key to specifying what to build for a given object in Nebula is always:

A state (or transition)

An object class name

A predefined scriptname (sometimes)

Map a scriptname to a physical scriptname, which either is a REXX or a java class to run. You can launch

more than one script in one script request. Within one physical script you can have as many internalsteps you want (codegen, compile etc). For each script, you can parse input from the datastore at all

levels (parent/child) in the hierachy relative to the object that needs to be built. There is absolutely nophysical application runtime definition in the profile. You define where the outcome of the script shouldbe placed in Nebula; for example, a load module goes to a given attribute. When you install the

application runtime, you can store the same files (such as DLLs) in different locations.

Build runtime propertiesis the container for all application runtime dependent libraries, mainframesubsystems, etc. It is release dependent; that is, there are different places to store the build outcome per

release. All Runtime key/value pairs are available to any script. The scripts then read the build profile andproperties files to determine what they need. You can easily add extra key/value pairs. The Build Servers(machines) available are defined here, although some physical Build Servers may be defined elsewhere.

Common runtime information is also placed here.

For each object inside Nebula, there will always be two attributes:

Script result

Dirty


29/46

Build Management


The script result is the file containing the log (outcome) of the build. Each new version of an objectoverwrites the content. Throughout the lifecycle, we append script results to the end: script result = oldscript result + new script result.

The Dirty attribute is used to determine an objects current build state within Nebula. This attribute

of an object is used to indicate if the object has changed since it was last built. If an object is marked as

'dirty', a build is required before the promotion of the object can take place.

For more information on build management, and customizing builds in Nebula, see Chapter 4,Customizing Integrated Builds.

Delivery

Nebula includes a release and delivery profile for specifying the configurations to be implemented. The

delivery system is set up per customer and can create full releases or deltas. It tracks all ERs delivered fora release. The delivery system takes care of extracting, packing, and loading items specified in thecustomer profile.

For more information on customizing the Nebula delivery, see Chapter 5, Customizing Delivery.


30/46


Build Management


31/46


CHAPTER

3

ARCHITECTURE


Nebula is fully integrated with Fujitsu Enabler 6.2 and BluePhoenix AppBuilder. It can also be

integrated with an external defect tracking system.

Requirements and installation procedures for installing and configuring Nebula with Enabler andAppBuilder are in the Installation Guidefor Nebula.

Nebulas client-server architecture includes:

Enabler Server

Enabler Server is only installed on the Datastore Server.

Enabler Client

Enabler Client is installed on all Clients and Build Servers.

Nebula Client

This is for all users of Nebula.

Nebula Runtime

Nebula Runtime needs to be installed on a file server that all Nebula users can access via a common

mapped drive.

Nebula ROM Server

Can be installed anywhere on Windows network. (Accessed via RMI)

Nebula API Server


Nebula Build Servers


AppBuilder

The AppBuilder installation must include a Personal Repository (LRE).

One way of installing these components is shown in the following figure:


32/46

28 Architecture

Figure 3-1 Conf igurat ion

Enabler

Enabler software includes both a server and a client piece. The Enabler server runs on Microsoft

Windows and UNIX platforms. It includes the repository services and the integration services forrepository access by local and remote clients. The system on which the Enabler server software resides iscalled the Enabler server or datastore server.

The Enabler client runs in a client/server environment. The Enabler client commonly runs on Microsoft

Windows clients. It includes Enabler tools and the integration services providing Windows clientapplications with access to the repository. Enabler clients and servers communicate using TCP/IP over a

local area network or wide area network.

Enabler stores the data in object-based datastores located on the Enabler server. An Enabler server may

hold one or more Enabler datastores. An Enabler environment may consist of multiple Enabler serversrunning on different platforms.

Enabler includes its own documentation package, including manuals in PDF format as well as a

complete online help system. For more information on Enabler and its features, see:

Enabler Overview


33/46


Enabler Concepts

Enabler Administration

AppBuilder

]

AppBuilder includes its own documentation package, including manuals in PDF format as well as acomplete online help system. For more information on AppBuilder and its features, see:

Getting Started Guide

Information Model Reference Guide

Rules Language Reference Guide

Developing Applications GuideDeploying Applications Guide

Table 3-1 AppBuilder Requirementsa

a. The complete list of the supported versions of each application is available on the

BluePhoenix support web site.

Software Requirement

Operating System Windows XP

Databases IBM UDB

CompilersJava JDK/JRE

MS Visual Studio C++

App Servers

WebSphere

WebLogic

Apache with Tomcat plug-in

Web Browser Internet Explorer Other Adobe Acrobat


34/46

30 Architecture


35/46


CHAPTER

4

CUSTOMIZING INTEGRATED BUILDS


With Nebula, you only build once. This significantly reduces CPU usage, since any project does not need

to go through repeated builds or move from development builds to stages of QA builds and finally to aproduction build. What is built in development and progresses through the lifecycle is precisely what

goes into production.

Nebulas build process includes a Build Manager which works with the Build Server(s) to create builds asspecified in the Build Profile.

Figure 4-1 Nebula Build Management

The Build Profile can be customized in many ways, since it serves as a configuration file for the builds.For example, the Build Profile is the container for all defined build scripts. However, the Build Profile is

also release-dependent, providing the user the ability to define different behavior for each release.


36/46

32 Customizing Integrated Builds

Build Profile

Different build lists can be provided. See the following table.

Build Profile

For builds, each object in Nebula always includes:

a state (or transition)

an object class name

The Build Profile uses the combination of these data as the key to what to build and how to build it. In a

Build Profile you can map a scriptname to a physical scriptname which is either a REXX or a Java class torun. You can launch more than one script from one script request. Within one physical script (REXX/Java) you can have as many internal steps as you want (codegen, compile, etc.). For each script, you can

parse the input from the datastore at all levels (parent/child) in the hierarchy relative to the object thatneeds to be rebuilt.

You can also define in the Build Profile where the outcome of the script should be placed in Nebula (that

is, for example, the load module being placed in a given location). When you install the applicationruntime files, you can store the same at different locations.

The Build Runtime is the container for all application runtime dependent libraries, mainframesubsystems, etc. The Runtime is release dependent, with different places to store build outcome for each

release. All runtime key/value pairs are available for all scripts.The scripts choose what they need. You

can easily add extra key-value pairs.

The available Build Servers are defined here, although some physical Build Servers may be definedelsewhere.

Build Scripts

A build script name is mapped to a physical build script name which is:

a Java class name at the client (LAN Build Server)

a REXX name at the host (Host Build Server)

Table 4-1 Bui ld l is ts

List type Description

Dirty list

(default)

Dirty list searches for all dirties from the object chosen and organizes

the build sequence as the hierarchy.

File list File list takes the input from a file and organizes the build sequence in apredefined way.

Lifecycle listLifecycle list takes the input from a lifecycle action and organizes the

build sequence in a predefined way.


37/46

Build Scripts


Figure 4-2 Workstat ion Bui ld Script

Each physical build script can have many internal steps and can use information from the profile thatmight impact the operation. It has all key/value pairs from Runtime available. Nebula also provides a list

of static methods.


38/46

34 Customizing Integrated Builds

Build Scripts


39/46


CHAPTER

5

CUSTOMIZING DELIVERY


Nebula includes a delivery system and configurable delivery profile, very similar to the customizable

build system. This system allows you to define a customer and a complete delivery profile in order toinsure that the customer receives only what is needed to run the application.

The customizable delivery system separates the Development center from the Production center. It also

offers a packaging facility per customer. Finally it generates and distributes only what has been testedand approved in the lifecycle process without rebuilding.

Nebulas delivery system also keeps track of the Enhancement Requests delivered in an application. It cancreate a full delivery or a delta delivery (only the Enhancement Requests not delivered earlier).

Figure 5-1 Del ivery opt ions

The delivery system can extract, pack and upload items as designed in the customer profile. Everything is

then placed on a delivery server.


40/46

36 Customizing Delivery

Delivery Process

Figure 5-2 Nebula del ivery process

Delivery Process

Nebulas delivery process begins with defining a customer. A customer can only be created in Productionor Test workspaces. In practice, it is a good idea to have a logical customer per release, even if the

customers are physically the same.

Figure 5-3 Def in ing a cus tomer

Once the customer has been created and defined, you can define a delivery profile. The profile specifiesinformation about the system and where it is located.


41/46

Delivery Profile


Delivery Profile

Figure 5-4 Def ining a del ivery prof ile

The delivery profile defines extract groups and behaviour, delivery uploads and behaviour, and relatesthem together.

Figure 5-5 Delegat ion of extraction

You can define in the delivery profile group, cycle, and attributes. At each level you can also define pre-

scripts and post-scripts.


42/46


Delivery Profile

Figure 5-6 Del ivery pro fi le

In the delivery profile, you also specify the upload behaviour, including source properties and target

properties.

Figure 5-7 Upload source properties

Figure 5-8 Upload Target propert ies

You can also specify the directory structure for the delivered files.


43/46

Delivery Profile


Figure 5-9 Extrac ted fi les

Figure 5-10 Packed f i les


44/46


Delivery Profile

Figure 5-11 Other files (delivery list)

Figure 5-12 Other files (ER Report)

Figure 5-13 Other files (Shipping list)


45/46

41

Index

INDEX

Product Name Version Document Title

Aaffects 8API Server 27

AppBuilder 1AppBuilder documentation 29

AppBuilder requirements 29architecture 27

attributes 15authorization 14

Bbuild 22, 31build files 23

build lists 32build management 2, 22Build Manager 31

Build Profile 31build profile 23, 24, 32

build results 23, 24build runtime properties 24

build script 23, 24, 31, 32, 33Build Server 31

build server 23, 27

Cchange management 2, 6, 12configuration 15

context 2, 14, 15controls 8

Ddata model 15

datastore 2, 14datastore server 28defining a customer 36

delivered files 38delivery 25, 35

delivery options 35delivery process 36

delivery profile 2, 25, 35, 37

delta 2developer 1, 14

development process 5, 7development stage 5

Development Task 1, 8development workflow 1

EEnabler client 27, 28

Enabler documentation 28Enabler server 27, 28Enhancement Request 1, 6, 14, 35

ER lifecycle 7

Ffeatures 1forward fit 2, 21

full package 2

Iimpact analysis 2, 8installing components 27integration 3, 11

Item 1, 8

Llifecycle

stages 1

lifecycle management 1lifecycle process 7

Mmethodology 5

NNebula 1


46/46

Nebula client 27Nebula runtime 27

Oobject 15

object class 15

Pparallel development 21

production stage 5promotion 2

promotion model 16properties 15

QQA 14

Rready for integration 10

ready for test 12relations 15

release 21, 22release contexts 21release coordinator 1

role management 14roles 1, 14

ROM Server 27

Sstages 5

stages of development 7

TTest context 12tester 1

Vverification stage 5

version 16, 21

versioning 2visibility 2, 14

Wworkspace 2, 15

Date post:	04-Jun-2018
Category:	Documents
Upload:	sadot-enrique-castillo-galan
View:	217 times
Download:	0 times

App Builderconcepts

Documents