BluePhoenix Nebula 2.

Product Concepts Guide

BluePhoenix Nebula 2.1 Product Concepts Guide October, 2005 Corporate Headquarters BluePhoenix Solutions The Netherlands Startbaan 5 B 1185 XP, Amstelveen +31 20 453 2107 +31 20 345 5030 fax

USA Headquarters BluePhoenix Solutions USA, Inc. 8000 Regency Parkway Cary, NC 27511 United 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 company names 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 furnished under a license agreement. Neither the software nor this document may be copied or transferred by any means, electronic or mechanical, except as provided in the licensing agreement. BluePhoenix Solutions has made every effort to ensure that the information contained in this document is accurate; however, there are no representations or warranties regarding this information, including warranties of merchantability or fitness for a particular purpose. BluePhoenix Solutions assumes no responsibility 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 by BluePhoenix Solutions or its representatives.

TABLE OF CONTENTS

Table of Contents

Nebula 2.1 Product Concepts Guide

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Lifecycle Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Build Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Visibility and Versioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

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

Lifecycle Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Enhancement Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Development Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Moving through the development process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Change Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Role Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Visibility and Versioning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Datastore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Workspaces and Contexts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Visibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Release Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Forward Fit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Build Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3 Architecture

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Enabler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 AppBuilder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

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

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

Nebula 2.1 Product Concepts Guide

5 Customizing Delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Delivery Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Delivery Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

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

ii

CHAPTER

INTRODUCTION

Nebula 2.1 Product Concepts Guide

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 is composed of an object-based change management system, a build management system, and releaselifecycle configuration management system. Nebula provides greater control, consistent quality, and a consistent process throughout your application development process. The system is based on an application development workflow methodology and enforces best practices throughout the lifecycle process 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 versioning capabilities which enables you to manage all components of your application throughout the development 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-driven development architecture.

Features
BluePhoenix Nebula is an open and extensible object repository. In addition to storing AppBuilderrelated 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-field application development, but also ongoing maintenance, enhancement, and support activity. Each change to the application follows a carefully-established methodology. Developers can promote changes from 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 the progress 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.

Nebula 2.1 Product Concepts Guide

Features

Change management involves the tracking and reporting of all modifications to any part of a development project during the development lifecycle. Nebula can integrate with an external change management 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 a new 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 the application 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 made to 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 AppBuilder applications 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 are to 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 visibility refers to the ability to see from any particular workspace (such as development or 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 contexts and workspaces for each release. Releases themselves are completely 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 delivery can 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.

Introduction

Features

Integration
Nebula has a number of ways to integrate with other tools. This includes simple invocation of other programs. 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. Nebula supports a callable import/export with AppBuilder. Other IDEs can be integrated the same way if they provide 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 table called 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 in order to extende import / export to other IDEs.

Nebula 2.1 Product Concepts Guide

Features

Introduction

CHAPTER

NEBULA IN THE DEVELOPMENT LIFECYCLE

Nebula 2.1 Product Concepts Guide

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 new features 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 it was 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 defects discovered in an application. The most common methodology is to separate the work into three progressive 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 existing features. Production Stage. In the final production stage, the change is accepted into the application and is actively used by the customers of the system. It is not sufficient merely to document the development workflow; its use must be enforced. So long as the 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 development organization. These problems can be avoided when the source code repository forces all work to progress through a strict development lifecycle.

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

Nebula 2.1 Product Concepts Guide

Lifecycle Management

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 tasks are often being started and completed at different times, and a number of tasks may be in progress when a 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 and time 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 the development 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 the development 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 a change ticket, engineering request, a recorded defect, or a new requirement. These change requests are usually 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, Nebula performs customizable Change Management Integration by notifying the external defect tracking system of any status changes. Note
For more information on integrating Nebula with external defect tracking systems (such as Customer First or Bugzilla) or collaboration and messaging applications (such as Lotus Notes), see BluePhoenix Product Support. Nebula Development Lifecycle

Figure 2-1

Nebula in the Development Lifecycle

Lifecycle Management

The development process moves changed components within a specified version and release from a development (work) context through integration and QA testing to a production context. A System Administrator 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 and associates the components with his assigned Development Task.
Figure 2-2 Process Flow

Nebula provides a process whereby each Enhancement Request for a designated release is tracked throughout 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 Enhancement Requests that have been promoted to the stage.

Nebula 2.1 Product Concepts Guide

Lifecycle Management

Development Tasks
At times an Enhancement Request is too large for a single engineer, especially in the case where complex new 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 identifies Items, development artifacts such as AppBuilder objects, bitmaps, documents, and source code that should be modified as part of the Development 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 of dependent Items that must be identified and changed before a successful build can take place. Nebula uses 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 happen independently of the build procedure. Figure 2-4 illustrates 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 Items at 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 the Items 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.

Nebula in the Development Lifecycle

Lifecycle Management

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. Note
Figure 2-5 In these illustrations of the lifecycle process, Enhancement Requests are represented by a triangle, Development Tasks by a square, and Items by a circle. ER in stage Started

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 can mark it as ready for integration.

Nebula 2.1 Product Concepts Guide

Lifecycle Management

Figure 2-6

Items ready for integration

When a developer has completed more Items and tasks, they too can then be moved to the ready for integration state. The parent Enhancement Request is still in the Work context and new tasks can still be added.
Figure 2-7 Task ready for integration

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 and all its Items to the stage ready for integration. This makes the Items accessible to other developers.

10

Nebula in the Development Lifecycle

Lifecycle Management

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

A developer can move the Enhancement Request and all its children from the state ready for integration 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. If individual 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

Nebula 2.1 Product Concepts Guide

11

Lifecycle Management

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

Change Management
Change management refers to the tracking of all modifications to data within the repository. Nebula provides 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 system integrated 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-created Enhancement Request becomes part of the Enhancement Request pool, and can then be assigned to a particular release and developer.

12

Nebula in the Development Lifecycle

Lifecycle Management

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 can be 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 defecttracking system.

Nebula 2.1 Product Concepts Guide

13

Visibility and Versioning

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 Roles to empower certain employees to promote an Enhancement Request from one stage to another. These roles are fundamental in 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 when coding 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 through Test by a person in the QA role. Nebula enforces lifecycle progression to improve the quality of the application.

Visibility and Versioning

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. These terms include datastore, workspace, context, and visibility.

14

Nebula in the Development Lifecycle

Visibility and Versioning

Datastore
Data is stored in Nebula in object-based datastores. The elements in a datastore and their interrelationships 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 each element 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 model includes 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 determine which 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. It also influences the visibility and accessibility of the instances. Nebula uses workspaces to model the development cycle for objects. That is, the datastore contains a hierarchical set of workspaces based on the stages of a development cycle (development, testing, and production). In this vertical hierarchy, each workspace 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 context determines 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 whether configurations are used. If configurations are used, it is also possible to set a working configuration.

Nebula 2.1 Product Concepts Guide

15

Visibility and Versioning

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 application with multiple objects in it, and the Development workspace contains newer versions of two rules. Tip
New versions of objects, whether rules, files, programs, or entire applications can always be created. No matter 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 it, the new version must be moved through the same stages as all other objects.

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

16

Nebula in the Development Lifecycle

Visibility and Versioning

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

Nebula 2.1 Product Concepts Guide

17

Visibility and Versioning

The testers working in the QA workspace can move rules R1, V2 and R2, V2 along to the In integration stage.
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 the application.

18

Nebula in the Development Lifecycle

Visibility and Versioning

Figure 2-19

New versions in staging

Visibility
Because the workspaces are operating as a hierarchy, the visibility of objects operates upwards. Thus, a developer working on Rule 1 in the Development workspace can see previous versions of Rule 1 in the QA and Staging workspaces above Development.

Nebula 2.1 Product Concepts Guide

19

Visibility and Versioning

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-21 illustrates the visibility from QA.
Figure 2-21 Visibility from QA

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

20

Nebula in the Development Lifecycle

Visibility and Versioning

Release Configuration
Nebula can version parts of an application or the whole application. This makes parallel development possible. Each release includes 5 contexts:
Table 2-1 Release contexts Description Urgent changes made directly to the current release All items that are ready for delivery Items currently in testing Integrating new items All items in development Release contexts Context name Hot Production Test Integration Work Figure 2-22

Whether a release includes minor fixes or major changes, each release is conceptually separate from one another. 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 whether to 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.

Nebula 2.1 Product Concepts Guide

21

Build Management

Figure 2-23

Forward Fit

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

Build Management
You must define builds and releases in 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 Build 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 the build has been installed into the Test workspace, an uninstall is performed in the Work workspace, unless a new version exists there.

22

Nebula in the Development Lifecycle

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 the following 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.

Nebula 2.1 Product Concepts Guide

23

Build Management

Figure 2-26

Build servers

A build profile is the container for all defined build scripts. It is release dependent; different behaviors per release 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 internal steps 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 no physical application runtime definition in the profile. You define where the outcome of the script should be 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 properties is the container for all application runtime dependent libraries, mainframe subsystems, 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 and properties 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

24

Nebula in the Development Lifecycle

Build Management

The script result is the file containing the log (outcome) of the build. Each new version of an object overwrites the content. Throughout the lifecycle, we append script results to the end: script result = old script 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 for a release. The delivery system takes care of extracting, packing, and loading items specified in the customer profile. For more information on customizing the Nebula delivery, see Chapter 5, Customizing Delivery.

Nebula 2.1 Product Concepts Guide

25

Build Management

26

Nebula in the Development Lifecycle

CHAPTER

ARCHITECTURE

Nebula 2.1 Product Concepts Guide

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 and AppBuilder are in the Installation Guide for 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 Can be installed anywhere on Windows network. (Accessed via RMI) Nebula Build Servers Can be installed anywhere on Windows network. (Accessed via RMI) AppBuilder The AppBuilder installation must include a Personal Repository (LRE). One way of installing these components is shown in the following figure:

Nebula 2.1 Product Concepts Guide

27

Figure 3-1

Configuration

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 for repository access by local and remote clients. The system on which the Enabler server software resides is called 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 client applications 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 servers running 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

28

Architecture

Enabler Concepts Enabler Administration

AppBuilder
]
Table 3-1 Software Operating System Databases Compilers AppBuilder Requirementsa Requirement Windows XP IBM UDB Java JDK/JRE MS Visual Studio C++ WebSphere WebLogic Apache with Tomcat plug-in Internet Explorer Adobe Acrobat

App Servers Web Browser Other

a. The complete list of the supported versions of each application is available on the BluePhoenix support web site.

AppBuilder includes its own documentation package, including manuals in PDF format as well as a complete 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 Guide Deploying Applications Guide

Nebula 2.1 Product Concepts Guide

29

30

Architecture

CHAPTER

4
Figure 4-1

CUSTOMIZING INTEGRATED BUILDS

Nebula 2.1 Product Concepts Guide

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 a production 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 as specified in the Build Profile.
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.

Nebula 2.1 Product Concepts Guide

31

Build Profile

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

Table 4-1 List type Dirty list (default) File list Lifecycle list Build lists Description Dirty list searches for all dirties from the object chosen and organizes the build sequence as the hierarchy. File list takes the input from a file and organizes the build sequence in a predefined way. Lifecycle list takes the input from a lifecycle action and organizes the build sequence in a predefined way.

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 to run. 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 that needs 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 application runtime files, you can store the same at different locations. The Build Runtime is the container for all application runtime dependent libraries, mainframe subsystems, 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 defined elsewhere.

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)

32

Customizing Integrated Builds

Build Scripts

Figure 4-2

Workstation Build Script

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

Nebula 2.1 Product Concepts Guide

33

Build Scripts

34

Customizing Integrated Builds

CHAPTER

CUSTOMIZING DELIVERY

Nebula 2.1 Product Concepts Guide

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 to insure 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 tested and approved in the lifecycle process without rebuilding. Nebulas delivery system also keeps track of the Enhancement Requests delivered in an application. It can create a full delivery or a delta delivery (only the Enhancement Requests not delivered earlier).
Figure 5-1 Delivery options

The delivery system can extract, pack and upload items as designed in the customer profile. Everything is then placed on a delivery server.

Nebula 2.1 Product Concepts Guide

35

Delivery Process

Figure 5-2

Nebula delivery process

Delivery Process
Nebulas delivery process begins with defining a customer. A customer can only be created in Production or 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 Defining a customer

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

36

Customizing Delivery

Delivery Profile

Delivery Profile
Figure 5-4 Defining a delivery profile

The delivery profile defines extract groups and behaviour, delivery uploads and behaviour, and relates them together.
Figure 5-5 Delegation of extraction

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

Nebula 2.1 Product Concepts Guide

37

Delivery Profile

Figure 5-6

Delivery profile

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 properties

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

38

Customizing Delivery

Delivery Profile

Figure 5-9

Extracted files

Figure 5-10

Packed files

Nebula 2.1 Product Concepts Guide

39

Delivery Profile

Figure 5-11

Other files (delivery list)

Figure 5-12

Other files (ER Report)

Figure 5-13

Other files (Shipping list)

40

Customizing Delivery

Index

INDEX
Product Name Version Document Title

A
affects 8 API Server 27 AppBuilder 1 AppBuilder documentation 29 AppBuilder requirements 29 architecture 27 attributes 15 authorization 14

delivery profile 2, 25, 35, 37 delta 2 developer 1, 14 development process 5, 7 development stage 5 Development Task 1, 8 development workflow 1

E
Enabler client 27, 28 Enabler documentation 28 Enabler server 27, 28 Enhancement Request 1, 6, 14, 35 ER lifecycle 7

B
build 22, 31 build files 23 build lists 32 build management 2, 22 Build Manager 31 Build Profile 31 build profile 23, 24, 32 build results 23, 24 build runtime properties 24 build script 23, 24, 31, 32, 33 Build Server 31 build server 23, 27

F
features 1 forward fit 2, 21 full package 2

I
impact analysis 2, 8 installing components 27 integration 3, 11 Item 1, 8

C
change management 2, 6, 12 configuration 15 context 2, 14, 15 controls 8

L
lifecycle stages 1 lifecycle management 1 lifecycle process 7

D
data model 15 datastore 2, 14 datastore server 28 defining a customer 36 delivered files 38 delivery 25, 35 delivery options 35 delivery process 36

M
methodology 5

N
Nebula 1

41

Nebula client 27 Nebula runtime 27

O
object 15 object class 15

P
parallel development 21 production stage 5 promotion 2 promotion model 16 properties 15

Q
QA 14

R
ready for integration 10 ready for test 12 relations 15 release 21, 22 release contexts 21 release coordinator 1 role management 14 roles 1, 14 ROM Server 27

S
stages 5 stages of development 7

T
Test context 12 tester 1

V
verification stage 5 version 16, 21 versioning 2 visibility 2, 14

W
workspace 2, 15

42

Index