If you’re still storing all your RPG, CL, and SQL source in traditional QSYS libraries, you’re missing out on one of the biggest productivity boosts available on IBM i today. The Integrated File System (IFS) is no longer just “that Unix-like thing over there” it’s the natural home for modern IBM i Source Code.

Twenty years ago, we all migrated our old AS400 code to modern ILE source files, didn’t we? QRPGLESRC, QCLLESRC became our repository of choice: If you are still storing your source code in the legacy old fashioned Source Files (QCLSRC, QRPGSRC, QDDSRC, etc) you should hang your head in shame! The IFS file structure gives modern IBM-i Developers a whole heap of coding improvements!

In this post, I’ll walk you through how to structure, organize, and keep your IFS-based source code clean, fast, and DevOps-friendly whether you’re using RDi, VS Code with Code for IBM i, or full CI/CD pipelines.

Why the IFS Is the Future of IBM i Development

Modern tools simply don’t play nicely with fixed-length members in QSYS. Here’s why the IFS wins:

• Tooling compatibility RDi and VS Code expect real files in a folder structure, not library members.
• Seamless Git & DevOps Git, Jenkins, GitLab CI, Azure DevOps – they all understand IFS paths perfectly.
• Flexibility Store RPGLE, CLLE, SQL scripts, DDS, binder source, documentation, and even build scripts side-by-side.

The result? Faster development, cleaner merges, easier collaboration, and builds that don’t take forever.

Recommended IFS Directory Structure for IBM i Projects

Here’s an example layout I use on almost every project. I separate application functions, common functions (service programs and the like) and database. Add some documentation and rogue objects in the assets location, and it scales beautifully from small utilities to enterprise applications:

/apps
  /ORDAPP           ← Order Entry application
  /INVAPP           ← Inventory application
/ile
  /srvpgm           ← Service program modules and binder source
  /binding          ← Binding directories and binder language files
/db
  /ddl              ← All SQL DDL scripts (tables, views, indexes)
/assets
  /savefiles        ← Exported .savf files for deployment
  /docs             ← PDFs, design specs, architecture diagrams

Why this structure works so well:

• /apps contains only the business logic (your RPG, CL, SQL) easy to navigate and share. Simple clear object naming like NICK010-Nicks_Order_Entry_Program.pgm.sqlrpgle tell you exactly what the IFS object is before you open it.
• /ile keeps ILE infrastructure separate no more hunting for binder source buried in an application folder.
• /db isolates database scripts perfect for schema migrations and review.
• /assets holds the heavy stuff (savefiles, PDFs) so developers don’t accidentally sync gigabytes of binaries every day.

Branching & Versioning the IBM i Way

Even on IBM i, Git (or any VCS) works the same way it does everywhere else:

• Main branch Always compiles cleanly and is production-ready.
• Feature branches Short-lived, focused on one change (e.g., “add-customer-search-rpg”).
• Release tags Tag stable builds (e.g., v2026.01.06) before deploying to test or production.

Pro tip: Use meaningful commit messages and keep merge conflicts small by merging frequently.

Performance & Storage Optimization Tips

Large IFS projects can slow down builds, backups, and Git operations. These quick fixes keep everything lean:

1. Separate binaries from source Keep .savf files, PDFs, and large logs in /assets. Developers rarely need them during coding.
2. Use selective sync or sparse checkout In Git, pull only the folders you’re working on: git sparse-checkout set apps/ORDAPP ile/srvpgm
3. Normalize line endings RPGLE and CLLE are plain text enforce LF (Unix-style) line endings everywhere to prevent massive noisy diffs.
4. Automate cleanup Add a simple CL program or PASE shell script to delete old .obj files, temporary builds, and orphaned logs from IFS.

Best Tools for IFS Development in 2026

• Visual Studio Code + Code for IBM i Lightweight, blazing fast, and loved by younger developers. Increasingly the gold standard for IBM-i code editing. Git works natively, extensions handle RPG syntax, SQL, and even 5250 green-screen sessions. My choice 🙂
• IBM Rational Developer for i (RDi) The official (very expensive) IBM toolset. Set up a “Remote Systems Project” pointing directly to your IFS folder instant compile, debug, and Git integration.

Both tools make IFS feel like any other modern codebase.

Quick Wins Every IBM i Team Can Implement Today

Here’s your 5-minute action list:

• Adopt a clear, consistent directory structure in IFS (use the one above as your template).
• Keep the main branch always buildable – no excuses.
• Segregate binaries and documentation away from source code.
• Store build and deploy scripts in /ile/build (CL wrappers or PASE shell scripts work great).
• Normalize line endings and enable sparse checkout for faster clones.

Final Thought

Moving your IBM i source to the IFS isn’t about “going modern for the sake of it.” It’s about making your life easier: faster edits, cleaner merges, reliable builds, and a workflow that plays nicely with the rest of the world.

Start small, move one application to the IFS using the structure above, set up VS Code or RDi, and you’ll never want to go back.

Have you already adopted IFS for your IBM i projects? What structure works best for you? Drop a comment below I’d love to hear your tips!

Happy coding.