The modern way.
Avalon connects your existing IBM i application with Git, VS Code and automated build and deployment processes. Your team works with modern tools, whilst development continues on IBM i.
IBM i
Application, source code and objects
Avalon
Record, prepare, build
Git & VS Code
Sectors, Development and Cooperation
WHAT IS AVALON?
A modern workflow for established IBM i applications.
Existing applications contain a wealth of knowledge – their development processes have often evolved over many years. Avalon captures source code, objects and dependencies, and prepares the source code for management in Git. Developers work in VS Code, whilst Avalon runs the builds on IBM i.
The application remains on IBM i. The way your team develops it is becoming more modern.
THE BENEFITS
Fewer disruptions in the development process.
From the handover of the existing application right through to delivery, tools and processes are seamlessly integrated.
01
Building on existing knowledge
Avalon identifies source members, objects, relationships and RPG includes, and prepares the application for Git.
02
Developers work on the source code locally and organise changes into branches.
03
Building and testing on IBM i
Builds run on IBM i. Modified objects are created in a separate workspace library for each user and branch.
04
Compile changes only
Avalon supports incremental compilation and returns build results and logs.
05
Builds and deployments can be integrated into CI/CD pipelines using standard automation tools.
06
The artefacts generated can be used for a traceable deployment to target libraries.
HOW YOUR TEAM WORKS
A development workflow that integrates Git and VS Code with the build process on IBM i.
01 / DEVELOP
Working in VS Code
Clone the repository and make changes in your own Git branch.
02 / BUILD
Start the build
Start the build from VS Code; Avalon compiles on IBM i.
03 / TEST
Test in isolation
Test modified items in the Workspace Library; logs and build results will reappear in VS Code.
04 / REWORKING
Repeat if necessary
Modify the code and run the build and test again.
05 / SHARE
Push changes
Commit the reviewed version and push it to the central Git repository.
Good to know:
Deployment takes place as a separate process via the CI/CD pipeline – it is not automatically part of every local build.
GETTING STARTED
When the application is loaded, Avalon scans the relevant libraries and identifies source code, objects and their relationships. Source members are prepared as stream files containing the information required for compilation.
Recording objects, source members and cross-references
Taking RPG and RPGLE includes into account
Mapping objects without traditional source code using pseudo-sources
Preparing source code for a Git repository
A SIMPLIFIED EXPLANATION
01 Analysing IBM i libraries
02 Capturing source code and relationships
03 Preparing for Git
AUTOMATION
From Git to deployment.
In a CI/CD pipeline, an automation server retrieves the code from Git and launches the Avalon build on IBM i. The resulting artefacts are stored and transferred to the target system as part of a separate deployment process.
01 / Git
Load code and branch
02 / Automation
For example, Jenkins or GitHub Actions
03 / Avalon on IBM i
Build, compilation and logs
04 / Artefact Repository
Save the file and store the deployment archive
05 / Deployment
Separate process: Update target libraries
The specific process and the tools used will depend on your existing infrastructure.
FREQUENTLY ASKED QUESTIONS
Will Avalon replace our IBM i application?
No. Avalon builds on the existing application and supports a modern development and deployment process. The builds continue to run on IBM i.
Do our developers need Git and VS Code?
The development process described on this page uses a Git repository and VS Code. Avalon links this local workflow with builds on IBM i.
Can Avalon be integrated into our CI/CD pipeline?
Yes. The processes described involve the integration of an automation server such as Jenkins, GitHub Actions or GitLab CI/CD. The specific integration will depend on your environment.
What happens when changes are tested?
The objects modified in the branch are created in a separate workspace library for the respective user and branch. The changes can be checked there before being pushed.
Get in touch.
Connect with knowledge.
Digital IT training, learning platforms, and customized solutions to help you advance.