Enterprise software release management

Use of software tools, processes, and project management procedures.

Over the past few decades, we have seen the evolution of the Enterprise Architecture, from the architecture of a single integrated circuit (the COBOL program running on the host) to component-based architecture (Java EE and Net Applications) and service-oriented architecture (transforming enterprises into a highly interoperable and reusable service set, it enables enterprises to better adapt to changing business needs ).

As the architecture method gradually develops towards the direction of more multiple application and separation, enterprise application software development constantly requires a clearly defined process and more multi-layer architecture technology. Therefore, enterprise application software development has increased complexity in some fields. Enterprise-level development (javaee ,. net), software providers have greatly reduced this complexity by providing advanced code generation and process automation tools, it also simplifies the complex aspects of enterprise development by using proven design patterns and best practices.

However, in the periphery of enterprise-level development, one of the aspects may often be ignored, which is the management of software release. Software Release administrators face the following challenges:

• Software defects
• Problem
• Risks
• Software change request
• New development request (additional features and features)
• Deployment and packaging
• New development task

These seem reasonable when you focus on isolating a single software release for a software application, ......

Considering that a highly complex transactional custom development application software is required, the software application development team should be able to develop new features or functions, and released to users (major versions) six times a year as usual ). The software application development team also needs to release 40-50 small versions (Representative enterprise archive files or. ear, or. jar, etc.), these are not any modifications, updates, or application software deployment in the plan or in the schedule.

In addition, application software depends on and depends on other software applications in the enterprise (in a successful build ).

What should the software release manager do?

This article describes how to use IBM Rational ClearQuest as a basic component to overcome the challenges faced by software release managers.

The purpose of this article is not to say that this new challenge or rational is the most important thing, but this challenge is becoming more and more complex with the needs of global delivery, time pressure and system integration. This solution focuses more on seeing rational as an activator than just a tool.

The software release manager can use the rational tool as an image"Project Management Association's project knowledge system guide"(PMBOK. PMBOK has identified nine knowledge fields:

1. Integration Management
2. Scope Management
3. Time management
4. Cost Management
5. Quality Management
6. Human Resource Management
7. Communication Management
8. Risk Management
9. Procurement Management

This article describes how this method and tool helps the software release manager to implement four fields in nine knowledge fields. These four fields are scope management, quality management, communication management, and risk management. This process goes through the concept of a well-known software release record. The software release record is a custom record type within Rational ClearQuest, which will be described in detail as a part in this article.

The remaining five fields and some parts of the other four fields will be processed by tool integration and they will not be involved. These integration tools include rational Portfolio Manager (RPM) or Microsoft Project.

Before we enter the release record and two closely related status-based record types, we should first figure out something similar to the definition provided by PMBOK.

Scope Management provides a guide to ensure that the project includes the work required to successfully complete the project, and only the work is included.

Quality management includes all the activities of the Organization that executes the quality policy, goals, and responsibilities, so that the project will meet all the requirements it undertakes.

Communication Management uses many processes to ensure timely communication and proper generation, collection, distribution, storage, modification, and final deployment.

Risk management processes focus on guiding risk management plans, identification, analysis, response, and monitoring.

So after all the constructed and useful industry acceptance definitions, what is the software release record?

A software release record is a status-based record type. It obtains data elements, such as the release manager name, Release number, release type (compliance or arbitrariness), and production environment deployment date (the time when the software is deployed to an application server) and the production date (the time when the software is usually available ).

Figure 1. Software release records

In this case, it is worth mentioning the numbering method of software release. It is worth mentioning because although it seems to be a trivial matter, I have seen many guesses and arguments about this topic. As a release manager, standards and processes are key to your overall success, although this article does not aim to introduce all the standards and methods necessary for an efficient release manager. One of the basic standards is the released coding conventions. The release code should follow an industry standard, such as the International Standards Organization (ISO ). The following chart provides a coding and publishing naming standard that can flexibly handle most of the Software Delivery statuses.

Figure 2. Release encoding standards

The software release record has a clear basic workflow to track the process in the software development lifecycle.

The following is the workflow of the software release record.

Figure 3. workflow of software release record

A software release record is a parent record of another State-based record type. It provides the release manager with a global view, but I'm sure you're asking yourself, how to manage a detailed view?

Further, we can generate two additional status-based record types, including incident and work request records.

The event record types can be classified as defects, problems, risks, change requests, etc. Due to these different categories, the event record types have a rather complex state conversion matrix:

Figure 4. event records

The event record type obtains the description, title (A brief description), owner name, priority, severity, and related software release records, related event records, and related work requests.

When an event record enters the slotted State, it must be associated with the software release record.

One of the complaints that users often hear is when they need to re-create a record, because it is very tedious to copy and paste the current record to a new record, although the work is simple, it is very error-prone. For example, you can paste a value into an incorrect field or forget to copy the value from the original record to a new record. To solve this problem, you can clone records without copying or pasting them. This not only creates a record and assembles data from the original record on the board, but also creates a link between the two records. The clone record code can be found in the Shmuel Bashan developerworks article in the resource section below.

The Code on developerworks must be dispersed into different scripts and operated with various event types. First scriptclone_record.zipIs to determine the type of the event record the user wants to clone, it will then execute an appropriate additional script to clone this record.

One of the limitations of using clearcase/UCM/ClearQuest for integration is that a record can only be allocated to one project/process/view, and can only be operated by one person at a time. However, it is likely that several people operate on a change at the same time or they may operate on the same change in different workflows in different places in the world.

To overcome this limitation, You can execute the job request record type. The job request record type is a status-based record type that can use the unified change management (UCM) package.

This work request record must be created within the event record, because many data elements are directly copied from the event record to the work request record, and these two records are later interconnected. This operation requires that the record can be used almost arbitrarily. It has a very short internal life cycle, because the user does not need to input a lot of data, this work request can be easily created, allocated, resumed, and closed. Once the developer completes the code change and passes the code review, the Unit Test change record will end. It will remind the event manager that the record is about to enter the next state.

The state conversion matrix of this job request record is very simple:

Figure 5. Status transition matrix of work request records

Although the software release records, event records, and work request records are correlated, the system can make some confirmation in two aspects. When an event record enters the resolved state, the system checks to ensure that all work requests related to this event are closed until those requests are closed, so that the recorded event record is allowed to enter the resolved state. A similar Validation occurs when the event record enters the closed state, because the Quality Assurance team may create a new work request to track their progress. Another confirmation occurs when the software release record is about to enter the deployed state. Before a software release record is allowed to enter the deployed state, the system will close the record confirming all relevant events.

Running event records

For further examples to illustrate the importance of the concept of event logging, the following describes a simple use case in rational application developer (IDE), rational clearcase (SCM), and Rational ClearQuest (problem tracking) complete integration exercises.

Figure 6. Rational clearcase (SCM) and Rational ClearQuest (problem tracking)

As described, event logging is an activator that associates the concept of an event (defect), event resolution (defect repair), and release tracking.

Use Cases:

• After testing, a software defect has been identified and entered as a ClearQuest event.
• Through ClearQuest, the defect Manager assigns the defect to an application developer for further analysis.
• The developer analyzes the defect and continues to position it. He accesses and debugs the code from rad ide.
• The dialog box prompts developers to associate code debugging with event records. developers can determine the appropriate event records and associate potential defect fixes with Software defects.
• After the defect location is determined in clearcase, the Project Manager or defect manager can control the progress, defect status, and release in the clearcase run report.
• Deployment and packaging
• New deployment task

Back to Top

Workpiece:

One of the artifacts produced by this method is the software release calendar, which can be categorized as the PMI Communication Management activator. This simple release calendar product uses Rational ClearQuest to query the specific time (days, weeks, months, and years) of a release record to provide a separate pre-release view. Other communication artifacts include but are not limited to logs (problems, risks, etc.) and reports (defects, changes, requests, etc ).

Figure 7. Logs and reports

Back to Top

Lessons learned:

• Ensure that the development team understands the benefits of release records and the methods for integrating software tools, processes, and project management disciplines.
• Communication, communication, or communication. Calendar publishing is a useful tool. It is one of the main resources to ensure that people use data publishing.
• If possible, use the standard. Do not copy the standard. For example, if there is a standard method of the software release number method, it can be used.
• Combine existing entities or create a Governance Board for software tools and processes.
• Make sure that your Tool Manager is insightful and understands your business environment and limitations.

Back to Top

Conclusion:

By using software tools, processes, and discussed project management principles, the software release manager can:

• There is a separately scheduled release view for the time frame (days, weeks, months, and years.
• Investigate complicated questions based on management requirements and Product matrices.
• You have the right to access the vast majority of current publishing information.
• Have more detailed insights on issues, risks, defects, deployment requests, and change requests for specific releases
• Generate a release calendar
• Gradually develop into more mature Software Configuration Management Programs
• Support and enable compliance with regulatory requirements like Sarbanes-Oxley Act 2002 (SOx) through tracking, historical collection, signature mechanisms, and other tool programming and customization features.
• Supports and uses the same process as the integrated Capability Maturity Model (cmme) through standard process and measurement collection
• He or she has a supportive opinion on related data, regardless of the time and location.

No matter what role you assume in an enterprise development project, whether it is a release manager, Project Manager, analyst, architect, development tester, Deployment Manager, or management, A powerful foundation for project management and software integrated into the integrated development environment (IDE), Software Configuration Management (SCM) systems, project management tools, and development methodology are all necessary.