Migration & Modernization

Automate the building, testing, and deployment processes of AWS Mainframe Modernization with AWS Blu Age

Introduction

Automating the building, testing, and deployment processes are a fundamental component of modern software development and delivery. By implementing a robust Continuous Integration (CI), Continuous Testing (CT), and Continuous Deployment (CD) pipeline organizations boost efficiency and accelerate time to market.

This blog post presents a Continuous Integration, Continuous Testing, and Continuous Delivery (CI/CT/CD) pipeline that automates compilation and functional equivalence testing in a flexible environment. It allows identifying issues and validating the application’s core functionality without the pressures or restrictions that exist in a production environment. After validation the pipeline deploys the application to a managed environment for acceptance testing or pre-production confirmation.

Implementing CI/CT/CD for refactored application with AWS Blu Age

Implementing CI/CT/CD adds value to software development and deployment processes. The value is in the ability to accelerate software development lifecycles, improve code quality, and increase overall efficiency and reliability of development and deployment processes. An AWS Blu Age refactored application is a modernized version of a mainframe application, transformed into a Java Spring Boot (backend) and Angular (frontend) application. The AWS Blu Age tooling enables the automated transformation of legacy applications written in COBOL, PL/I, RPG/400 into modern applications. This approach preserves the investment in existing business logic while providing benefits like:

  • Increased agility through the use of newer technologies
  • Access to a larger talent pool of developers familiar with modern stacks
  • Accelerated modernization projects

The refactoring process transforms the underlying databases and data models to a modern format, enhancing the application’s capabilities and compatibility.

Establishing a CI/CT/CD pipeline with continuous testing is essential to ensuring functional equivalence between legacy and modernized systems. Since testing can consume 60–70% of a modernization project’s effort and budget, automating it is crucial for quickly realizing business value.

The CI/CT/CD pipeline stages

The pipeline is made up of five stages:

  1. Application source code retrieval
  2. Application build
  3. Functional equivalence testing of the application
  4. Manual approval
  5. Deployment in a managed environment

Architecture and Deployment for CI/CT/CD pipeline

Figure 1 outlines the five stages of the CI/CT/CD pipeline modeled using AWS CodePipeline. The associated infrastructure is provisioned through AWS CloudFormation.

CloudFormation is a powerful infrastructure as code service that enables infrastructure provisioning, reusability, consistency, and reliability to model the required resources to run the application.

AWS CodePipeline is a Continuous Integration and Continuous Delivery service. It models and automates software release processes. A pipeline defines the workflow, describing how code changes progress through development and deployment stages. Each stage of the pipeline is made up of a sequence of actions, which are tasks such as building code or deploying to test environments.

Architecture diagram of the CI/CT/CD pipeline

Figure 1 – Architecture diagram of the CI/CT/CD pipeline

The next sections of the blog describe the tasks of each stage depicted in the architecture diagram.

Stage 1 – Application code retrieval

Prerequisites

  • A Git repository is created and configured for the development team.
  • The application source code, generated from AWS Blu Age Transformation Center, is loaded into the Git repository.
  • AWS CodePipeline is set up and configured to be activated on commits to the main branch of the Git repository.

Development Process

  1. Developer clones the Git repository to their local development environment.
  2. Developer creates a new branch for their feature or bug fix.
  3. Developer makes necessary code changes, following the team’s coding standards and best practices.
  4. Developer runs local tests to ensure code quality and functionality.
  5. Developer commits changes to their local branch with descriptive commit messages.
  6. Developer pushes the branch to the Git repository.

AWS CodePipeline Activation

The merge into the main branch automatically activates the AWS CodePipeline.

Stage 2 – Application build

AWS CodePipeline initiates the AWS CodeBuild step as part of the CI/CT/CD pipeline. In this step, AWS CodeBuild uses AWS Blu Age Build Tools to build modernized Java applications transformed from legacy languages.

Build Process

  1. CodeBuild fetches the source code from the previous pipeline stage.
  2. CodeBuild connects to AWS CodeArtifact to download the required AWS Blu Age runtime libraries.
  3. Two distinct WAR (Web Application Archive) files are generated:
    • Frontend application composed of static website assets, including HTML, JavaScript, and CSS files. This structure allows for flexible deployment options. The frontend can be hosted on various Content Delivery Network (CDN) solutions, such as Apache HTTP Server or Amazon CloudFront, optimizing content delivery and user experience.
    • Backend application.
  4. CodeBuild stores the WAR files securely in Amazon S3

This approach facilitates a clear separation between frontend and backend components, enabling independent scaling and management of each tier. It also allows for the possibility of deploying the frontend to edge locations for reduced latency, while the backend can be hosted in a more controlled environment for enhanced security and data management.

Stage 3 – Application functional equivalence testing

To ensure functional equivalence between the legacy mainframe applications and their modernized counterparts on AWS Cloud, AWS Mainframe Modernization Application Testing is employed. This testing framework is designed to validate the consistency of functionality throughout the modernization process.

Prerequisites

Testing team creates following artifacts within AWS Mainframe Modernization Application Testing

  • Test cases: These represent the smallest unit of testing actions. When creating a test case, users identify the data types to be compared, which represent functional equivalence between source and target systems.
  • Test suites: These are series of test cases executed sequentially.
  • Test environment configuration: This includes all necessary parameters and resources for conducting repeatable tests. A CloudFormation template is utilized to set up the initial data and configuration parameters (resources) required for running repeatable tests in the test environment. This approach ensures consistency and reproducibility across testing iterations.

Testing process

The testing process comprises three key stages:

  1. Record

  • Users create reference data on the mainframe for each test case
  • This reference data encompasses artifacts, data sets, and relational database Change Data Capture(CDC) journals from the source mainframe
  • The Record stage is typically performed once at the project’s outset to capture all necessary reference data

  1. Replay

  • The service executes the test suite in the target environment
  • It captures datasets, database changes, and 3270 screens generated by individual test cases

  1. Compare

  • The service conducts a thorough comparison between the source testing reference data and the target replay data
  • Results are categorized as identical, different, equivalent, or missing data
  • Comparison outputs are stored in Amazon S3 for review by designated approvers

The CI/CT/CD pipeline automatically initiates the Replay and Compare stages, ensuring consistent and repeatable testing throughout the development process.

The primary objective of this testing is to validate the modernized application behaves identically to the mainframe application. This is achieved by meticulously identifying any discrepancies between the reference and replay data, thereby ensuring a successful and reliable modernization process.

Stage 4 – Manual approval

Pipeline Pause

After completion of functional equivalence testing, the AWS CodePipeline automatically halts at the manual approval stage before deploying to pre-production or acceptance environments.

Approval process

  1. AWS CodePipeline notifies relevant stakeholders such as a project manager, quality assurance (QA) lead, or designated reviewer about pending review
  2. The reviewer accesses comparison reports stored in Amazon S3. These reports contain
    1. Reference data
    2. Replayed data
  3. The reviewer examines and approves the reports. This resumes the AWS CodePipeline.

Stage 5 – Application deployment in a managed environment

The last stage consists of deploying the approved application in the AWS Mainframe Modernization Automated Refactor Managed runtime. AWS CodeBuild is used to invoke a script (like Python script) leveraging the AWS Cloud Development Script (AWS CDK). The script performs tasks based on scenarios:

Scenario 1: AWS Mainframe Modernization Environment doesn’t exist, checked using AWS Systems Manager (SSM) Parameter Store. The AWS CodeBuild step:

  1. Creates the AWS Mainframe Modernization managed runtime environment and stores environment ID in SSM.
  2. Creates the Mainframe Modernization application and store application ID in SSM.
  3. Deploys the application into the managed runtime.
  4. Starts the application.

Scenario 2: AWS Mainframe Modernization Environment and Application already exists. The AWS CodeBuild step:

  1. Stops the running application.
  2. Update the application to create a new version in the AWS Mainframe Modernization Managed runtime environment to reflect new archive files.
  3. Starts the application.

For near 100% availability of the environment and application, use blue/green deployment, where blue refers to the current active instance and green refers to the new instance. Traffic is redirected to the green instance after testing, allowing rollback by redirecting traffic to the blue instance if issues arise. This would be implemented as:

Scenario 1: AWS Mainframe Modernization environment doesn’t exist, checked using AWS Systems Manager (SSM) Parameter Store. The AWS CodeBuild step:

  1. Creates two AWS Mainframe Modernization Managed runtime environments (blue and green) and stores their environment IDs in SSM.
  2. Creates the Mainframe Modernization application and store application ID in SSM.
  3. Deploys the application into one of the managed runtime environments created. Mark this as environment ID in SSM (blue environment).
  4. Starts the application.

Scenario 2: AWS Mainframe Modernization Environment and Application already exists. The AWS CodeBuild step:

  1. Creates new Mainframe Modernization application to reflect the new archive files.
  2. Deploys the new application into the green AWS Mainframe Modernization Environment.
  3. Starts the application.
  4. Switches traffic to a green environment by updating application references in Amazon Route 53 and batch execution to reflect new application attributes.

For scenario 2, the CI/CT/CD pipeline requires manual approval before proceeding. This step stops/deletes the previous application and updates the green environment as blue and the reverse in the SSM.

Benefits of using Infrastructure as Code (IaC) within AWS Mainframe Modernization service

Infrastructure as code has multiple features that benefit developers and business owners. These are the top benefits:

  • Automates and accelerates infrastructure provisioning, like networking, computing and database management. It simplifies procedures with code, enhancing efficiency and speed for teams
  • Mitigates human errors in manual infrastructure provisioning and configuration. It provides standardized, documented procedures and logs, which can facilitate new employee onboarding
  • Enhances consistency in deployment and configuration by reducing human errors and incompatibilities, preventing resource wastage and downtime
  • Repeatable, ensuring consistent redeployments and automatically correcting configuration drift by maintaining predefined environment specifications
  • Enhances security by standardizing and automating the provisioning and deployment of services and security standards, reducing the need for frequent security reviews and approvals

Summary

This post reviews the benefits of using the AWS Mainframe Modernization service, a service that refactors legacy applications into modern applications while preserving existing business logic. It combines the service with AWS Mainframe Modernization Application Testing and a CI/CT/CD pipeline to accelerate software development and deployment. CI/CD pipelines, integrated with automated testing, ensure functional equivalence between legacy and modernized systems, enabling efficient validation of core functionality and smooth deployment to managed environments. This approach increases agility, enhances operational efficiency, and provides access to a wider developer talent pool, contributing to successful modernization projects. To learn more, visit the AWS Mainframe Modernization page.

About the Author