IBM i applications may be known for stability, but the way organizations develop, test, and deploy those applications does not have to remain unchanged.

Development teams today are expected to deliver enhancements faster, respond to changing business requirements, integrate with more applications, and maintain increasingly complex environments.

For IBM i teams, that makes DevOps an increasingly important part of modernization.

IBM i DevOps is not about replacing RPG or abandoning the platform. It is about applying modern development practices such as source control, automated testing, continuous integration, repeatable deployments, and better collaboration to the applications your organization already depends on.

The result can be a development environment that is faster, easier to manage, and better prepared for long-term modernization.

What Is IBM i DevOps?

DevOps combines development practices, operational processes, and automation to improve how software changes move from development into production.

For an IBM i team, this may include:

• Git-based source control
• Modern RPG development tools
• Automated builds
• Automated testing
• Code review
• Continuous integration
• Repeatable deployments
• Application monitoring
• API testing
• Development documentation

The goal is not simply to deploy software faster.

The goal is to make software delivery more predictable, repeatable, and reliable.

Why Traditional IBM i Development Workflows Are Changing

Many IBM i environments were built around development practices that worked extremely well for years.

But organizations now face different expectations.

Applications need to connect with:

• Cloud platforms
• Mobile applications
• Customer portals
• eCommerce systems
• SaaS applications
• Analytics platforms
• AI applications
• Third-party APIs

Development teams also need to support more frequent changes while maintaining the reliability IBM i users expect.

Traditional processes that rely heavily on manual steps can become bottlenecks.

Examples include:

• Manually tracking source changes
• Moving objects between environments by hand
• Testing changes inconsistently
• Maintaining undocumented deployment procedures
• Depending on one developer’s knowledge of a particular application

Modern development practices can help reduce these dependencies.

1. Start with Modern Source Control

Source control is one of the foundations of DevOps.

Git gives development teams a structured way to manage source changes, maintain version history, collaborate, and review code.

For IBM i teams, Git can help answer important questions:

• Who changed this program?
• What changed?
• Why was it changed?
• Which version is currently in production?
• Can we restore an earlier version?
• Which changes belong to a particular release?

This becomes increasingly valuable as more developers contribute to IBM i applications.

Why Git Matters for RPG Teams

Modern source control can help teams:

• Improve collaboration
• Maintain a clear change history
• Simplify code reviews
• Reduce accidental overwrites
• Support parallel development
• Improve disaster recovery for source code

It also makes IBM i development more familiar to developers coming from other technology environments.

2. Modernize the RPG Development Experience

DevOps is easier when developers have tools that support modern workflows.

IBM i development teams are increasingly combining RPG with practices familiar to developers working in other languages.

That may include:

• Modern code editors
• Git integration
• Free-form RPG
• Automated formatting
• Code analysis
• Reusable procedures
• API documentation
• Integrated testing

The objective is not to make RPG behave like another programming language.

It is to remove unnecessary friction from the development process.

Modern RPG applications can still take advantage of the reliability and performance of IBM i while benefiting from contemporary development practices.

3. Introduce Continuous Integration

Continuous integration, commonly called CI, means regularly combining code changes and automatically validating them.

A simplified IBM i CI workflow might look like this:

1. A developer updates RPG source.
2. The change is committed to source control.
3. An automated process retrieves the change.
4. The application is compiled.
5. Automated checks are performed.
6. Tests are executed.
7. The team is notified if something fails.

Instead of discovering integration problems late in the release process, teams can identify them closer to when the change was made.

That can make problems easier and less expensive to correct.

4. Automate Testing Where It Makes Sense

Testing is one of the most valuable areas for automation.

IBM i applications frequently contain critical business logic around:

• Pricing
• Inventory
• Orders
• Financial calculations
• Customer rules
• Production
• Shipping

Changes to these applications need to be validated carefully.

Automated testing can help teams verify that expected behavior continues after a change.

For example, a pricing routine could be tested using known inputs and expected outputs.

If a future development change produces a different result, the test can flag the issue before deployment.

Automated Testing Does Not Replace Human Testing

Not every IBM i process can or should be fully automated.

Business users may still need to validate:

• User experiences
• Complex workflows
• Unusual business exceptions
• New functionality

Automation is most effective when it handles repeatable tests so people can spend more time evaluating higher-value scenarios.

5. Make Deployments Repeatable

Production deployments can become risky when they depend on a long list of manual steps.

A developer may need to:

• Compile several programs
• Move objects
• Update configuration
• Restart services
• Verify dependencies
• Run database changes
• Test integrations

Missing one step can cause problems.

DevOps encourages teams to turn deployment procedures into repeatable processes.

This can include automated or standardized steps for:

• Building applications
• Moving approved objects
• Applying configuration
• Updating APIs
• Running validation checks
• Recording deployment results

The goal is consistency.

A deployment should not depend entirely on who happens to perform it.

6. Bring APIs into the Development Pipeline

As IBM i environments become more connected, APIs should be treated as software products rather than one-time integrations.

An IBM i API development process should consider:

• Source control
• API documentation
• Versioning
• Security testing
• Functional testing
• Performance testing
• Deployment
• Monitoring

If an RPG program exposed through an API changes, teams need to understand whether that change could affect connected applications.

Automated API testing can help verify that expected requests and responses remain consistent.

This becomes increasingly important as IBM i APIs support customer portals, mobile apps, cloud systems, automation, and AI applications.

7. Use DevOps to Improve API Security

DevOps can also help organizations integrate security earlier in the development process.

Rather than waiting until deployment to evaluate security, teams can build security checks into development workflows.

Examples include:

• Reviewing authentication requirements
• Validating authorization
• Checking API configuration
• Testing invalid inputs
• Reviewing dependencies
• Protecting credentials
• Monitoring production behavior

This approach is often described as DevSecOps because security becomes part of the development lifecycle instead of a final checkpoint.

For IBM i integrations, this can help teams identify security issues before APIs reach production.

8. Connect Development and Production Monitoring

DevOps does not end when software reaches production.

Monitoring provides feedback that can improve future development.

Teams can track:

• API response times
• Application errors
• Failed transactions
• Job performance
• Resource consumption
• Integration failures
• Authentication errors

When developers have visibility into production behavior, they can better understand how applications perform under real-world conditions.

Monitoring can also help teams identify recurring problems that should be addressed through development rather than repeatedly handled as support incidents.

IBM i DevOps and the Skills Gap

Modern development practices can also help address one of the IBM i community’s biggest challenges: knowledge transfer.

In environments where critical processes depend on a small number of experienced developers, undocumented procedures create risk.

DevOps encourages teams to capture knowledge through:

• Source-control history
• Code reviews
• Automated tests
• Deployment scripts
• Application documentation
• Standard development processes

This makes application knowledge more accessible to the broader team.

A new developer may not immediately understand every RPG program, but a well-documented repository, automated test suite, and repeatable build process can significantly shorten the learning curve.

DevOps Can Support Incremental Modernization

One of the biggest benefits of IBM i DevOps is that organizations do not need to modernize everything at once.

DevOps practices can be introduced gradually.

A team might begin with:

Phase 1: Source Control

Move selected RPG source into Git and establish basic version-control standards.

Phase 2: Code Review

Introduce peer review for important application changes.

Phase 3: Automated Builds

Create repeatable build and compile processes.

Phase 4: Automated Testing

Start with high-value business logic that has predictable inputs and outputs.

Phase 5: Continuous Integration

Automatically build and test approved changes.

Phase 6: Deployment Automation

Standardize how applications move between development, test, and production environments.

Phase 7: Continuous Monitoring

Use production data to identify performance and reliability improvements.

This incremental approach allows teams to gain experience without disrupting critical applications.

Where APIs Fit into IBM i DevOps

APIs and DevOps complement each other.

APIs make IBM i business functions easier for other applications to consume.

DevOps makes those APIs easier to develop, test, deploy, and maintain.

Together, they can create a modernization model where:

RPG provides trusted business logic.

APIs provide connectivity.

DevOps provides repeatability and control.

That combination allows IBM i teams to modernize without abandoning the platform or rewriting proven applications.

Measuring the Impact of IBM i DevOps

DevOps should produce measurable improvements.

Organizations can track metrics such as:

• Deployment frequency
• Development lead time
• Failed deployment rate
• Time required to restore service
• Number of manual deployment steps
• Automated test coverage
• API error rates
• Production incidents
• Developer onboarding time

The goal is not to maximize deployment frequency simply because other development teams deploy frequently.

The right metrics depend on the business.

For an IBM i environment supporting mission-critical operations, improving reliability and reducing deployment risk may be more valuable than dramatically increasing release frequency.

Common IBM i DevOps Mistakes to Avoid

Trying to Automate Everything Immediately

DevOps is a process, not a single technology implementation.

Begin with the areas where automation provides clear value.

Ignoring Existing Business Knowledge

Experienced IBM i developers understand business rules that may not be documented anywhere else.

Modernization should capture that expertise, not work around it.

Buying Tools Without Changing Processes

Tools alone do not create DevOps.

Teams also need clear responsibilities, development standards, review processes, and documentation.

Measuring Speed Without Measuring Quality

Faster releases provide little value if they create more production problems.

Reliability should remain central to IBM i development.

Treating APIs as One-Time Projects

APIs need ongoing testing, versioning, security, documentation, and monitoring just like other production software.

Frequently Asked Questions About IBM i DevOps

What is IBM i DevOps?

IBM i DevOps applies modern software development practices such as Git source control, automated testing, continuous integration, standardized deployment, and monitoring to IBM i applications and RPG development.

Can RPG development use DevOps?

Yes. RPG applications can benefit from source control, automated builds, testing, CI/CD workflows, code review, and other modern development practices.

Does IBM i DevOps require rewriting existing RPG applications?

No. DevOps focuses primarily on improving how applications are developed, tested, deployed, and maintained. Existing RPG applications can be modernized incrementally.

What is CI/CD on IBM i?

CI/CD refers to continuous integration and continuous delivery or deployment. On IBM i, this can include automatically building RPG applications, running tests, validating changes, and creating repeatable processes for moving approved software between environments.

Can DevOps improve IBM i API development?

Yes. DevOps practices can help teams manage API source code, automate testing, maintain documentation, control versions, standardize deployments, and monitor production APIs.

How does DevOps help with the IBM i skills gap?

Modern source control, documentation, automated tests, code reviews, and repeatable processes reduce dependence on individual developers and make applications easier for new team members to understand.

Does IBM i DevOps improve security?

It can. DevSecOps practices incorporate security checks, authentication testing, configuration reviews, and other controls earlier in the development lifecycle.

Where should an IBM i team start with DevOps?

Source control is often a practical starting point. From there, teams can gradually introduce code review, automated builds, testing, continuous integration, deployment automation, and monitoring.

Final Thoughts

IBM i modernization is not only about what applications can do.

It is also about how those applications are built, tested, deployed, and maintained.

Modern development practices can help IBM i teams deliver changes more confidently while protecting the reliability that makes the platform valuable in the first place.

By combining RPG with source control, automated testing, CI/CD, APIs, security, and monitoring, organizations can create a development environment that is easier to manage and better prepared for the future.

IBM i does not need to become less IBM i to modernize.

The platform can continue running trusted business logic while the development practices around it evolve.

And for many organizations, that may be one of the most important modernization steps they can take.