43-2 · Chapter 43 · 6 min read

Before You Plan Your CI/CD Roadmap, Take Inventory First

You sit down with your team to plan the CI/CD implementation. Someone suggests starting with the most critical application. Someone else wants to fix the

Before You Plan Your CI/CD Roadmap, Take Inventory First

You sit down with your team to plan the CI/CD implementation. Someone suggests starting with the most critical application. Someone else wants to fix the deployment process that causes the most pain. A third person argues for building a new pipeline from scratch. Everyone has a valid point, but nobody knows for sure what the team actually has to work with.

This is where most CI/CD roadmaps fail. They start with decisions before understanding the current state. You cannot prioritize what to change if you do not know what exists. The first step is not planning. The first step is inventory.

What You Need to Catalog

Inventory sounds administrative, but it is the foundation for every decision that follows. Without it, you are guessing which changes matter most. With it, you see patterns, gaps, and dependencies that would otherwise remain invisible until they block your progress.

Applications

Start with every application your team manages. Include the ones that rarely change, the internal tools nobody talks about, and the legacy systems everyone avoids. For each application, record:

Programming language and framework
Where the source code lives (repository, branch strategy)
How the build process works today (manual commands, scripts, existing automation)
Who knows the application best

The last point matters more than it seems. When you start modifying pipelines for a specific application, you will need someone who understands its quirks. That person is your primary resource. Without them, you will make assumptions that break things.

Databases

Many teams forget that databases are part of the delivery process. A CI/CD pipeline that handles application code but ignores database changes will fail the moment a migration runs in production. For each database connected to your applications, note:

Database type and version
How schema changes are currently managed (manual scripts, migration tools, nothing at all)
Who handles database changes and who responds when migrations fail
Whether database changes are tested before reaching production

Database changes carry different risks than application code changes. A bad deployment can often be rolled back quickly. A bad migration can corrupt data or require hours of recovery. Knowing your database landscape helps you decide how much automation and testing to apply.

Infrastructure

Applications and databases run somewhere. Record where that somewhere is for every component:

Physical servers, virtual machines, or cloud services
How environments are created and configured
Whether configuration is documented or managed through manual SSH sessions
Who has access to production environments
Who typically handles infrastructure issues

Infrastructure that is managed manually will limit how much automation you can introduce. If every server is a snowflake with unique configuration, your pipeline cannot reliably deploy to any of them. The inventory will show you which parts of your infrastructure are ready for automation and which need cleanup first.

Existing Pipelines

Your team may already have some automation in place, even if it is incomplete. Document what exists:

Which applications have automated build, test, or deployment processes
What each pipeline actually does (build only, build and test, full deployment)
What is missing (no security scanning, no database migration, manual approval steps)
How reliable the existing pipelines are (frequent failures, flaky tests, long run times)

Existing pipelines are not useless just because they are imperfect. They show you what the team has already figured out and where the gaps are. A pipeline that builds and tests but deploys manually tells you where to focus next.

Ownership

Every component needs an owner. Record who is responsible for each application, database, and infrastructure piece. Ownership matters because pipeline changes require coordination. You cannot modify the pipeline for an application owned by another team without involving them. You cannot change how a database migration runs without talking to the person who handles database changes.

Also note who can make decisions about changes. The person who maintains a component may not be the person who approves changes to it. Knowing the decision chain prevents delays later.

How to Build the Inventory

Do not aim for perfection. A complete but rough inventory is better than a polished but partial one. Use whatever tool your team finds comfortable: a spreadsheet, a shared document, a digital whiteboard. The format matters less than the content.

The following flowchart outlines the recommended inventory process:

flowchart TD A[Start Inventory] --> B[List Applications] B --> C[List Databases] C --> D[List Infrastructure] D --> E[List Existing Pipelines] E --> F[Assign Ownership] F --> G[Review with Team] G --> H[Identify Gaps] H --> I[Analyze Patterns] I --> J[Plan Roadmap]

Start with what you know. Fill in the obvious entries first, then ask team members to verify and complete their areas. Schedule a short meeting where everyone reviews the inventory together. This often reveals components that were forgotten or dependencies that were assumed but never confirmed.

Expect to find gaps. Some applications may have no clear owner. Some databases may have undocumented migration processes. Some infrastructure may be running on credentials that nobody remembers. These gaps are not failures. They are the exact information you need to plan your next steps.

What the Inventory Reveals

Once the inventory is complete, patterns emerge. You might see that one team has a mature pipeline while another team still deploys manually. You might find that database changes are handled carefully but infrastructure provisioning is chaotic. You might discover that your most critical application has the least automation.

These patterns tell you where to start. The team with the mature pipeline can serve as a model. The application with manual deployment but clear ownership is a good candidate for automation. The database that already has migration scripts is easier to integrate into a pipeline than one that has never been versioned.

The inventory also reveals dependencies you cannot ignore. An application that depends on a database with no migration process cannot be fully automated until the database side is addressed. An application that runs on manually configured infrastructure will need infrastructure changes before the pipeline can deploy reliably.

Practical Checklist

Use this checklist to guide your inventory effort:

List every application your team manages, including internal and legacy systems
For each application, record language, repository, build process, and primary contact
List every database connected to those applications
For each database, record type, version, migration process, and responsible person
Document where each application and database runs (server, VM, cloud)
Note how environments are created and configured
Document existing pipelines: what they do, what they miss, how reliable they are
Record ownership for every component
Identify who can approve changes for each component

The Concrete Takeaway

Inventory is not a bureaucratic exercise. It is the single most useful thing you can do before planning any CI/CD improvement. A team that knows exactly what they have can make decisions based on facts rather than guesses. A team that skips inventory will keep discovering surprises halfway through implementation, and those surprises will cost time, trust, and momentum.

Start your roadmap by knowing what you already own. The patterns in your inventory will tell you where to go next.