Skip to main content
Version: 0.1.125 – latest

Creating a project

A project pairs one legacy codebase with the modern codebase being built from it. Everything else — the specification, the implementations, the test runs — hangs off that pair.

Before you start​

You need edit access to create a project, and your installation needs a valid licence. An unlicensed installation will tell you so on every screen and explain how to get one.

The legacy codebase​

Upload the legacy source as an archive. A few things happen to it on the way in, and it is worth knowing about them because they change what you see afterwards.

  • Oversized uploads are refused, not truncated. If the archive exceeds the limit your operator configured, the upload fails and nothing is stored. A partially ingested codebase would produce a specification with holes in it and no sign that anything was missing.
  • An archive that expands without bound is refused mid-extraction, and a refused upload leaves nothing behind.
  • A single wrapping folder is flattened. If your archive contains one top-level directory with the project inside it, that directory is unwrapped rather than treated as the codebase root.
  • Non-UTF-8 source is converted before anything reads it. Legacy code in a regional encoding would otherwise reach the analysis as mojibake. The originals are kept, and a project ingested before conversion existed is found and offered one.

The modernized codebase​

There are two ways to get one, and the choice is made when the project is created.

Scaffolded. The platform generates a new application on the target stack you choose, and owns its structure from the start.

Provided. You point the project at a repository you already have — a Git server, GitHub, Azure DevOps, or Team Foundation Server — and the platform clones it. A provided codebase needs two things declared that a scaffolded one does not:

  • Its toolchain, so agents build and run it the way you do.
  • Its unit test configuration — where the suites are, how to run them, how coverage is reported. The platform detects this by running the suites, and reports why it will not run if detection fails rather than guessing.

Connecting to a repository​

GitHub and Azure DevOps connect with a personal access token. Team Foundation Server connects without deployment configuration, and where your server presents a private certificate authority you can trust it from the UI, or skip TLS verification for that one connection if you must.

Projects that combine several repositories​

A system split across several repositories can be one project. The source repositories are managed from project settings, changes are pulled in from each, and work done in the combined workspace is pushed back out to the repositories it belongs to.

What runs on upload​

Ingestion is not the end of it. The platform indexes the codebase, counts what is there, and begins the analysis that produces the as-is specification. You can watch this on the Analysis Jobs page — see Jobs — and you do not have to wait on that page for it to proceed.

The code index is a separate thing worth knowing about: two project settings decide whether it runs, it says what state it is in, and it can be rebuilt. Each codebase in a project is indexed separately and each is kept current as commits land.

When it is ready​

The project summary shows lines of code for the legacy and modernized codebases, and feature coverage closure — how much of what was discovered has been decided and built. When features start appearing under Discovered Features, the analysis has produced something to review.

Next: Reading the analysis.