New products

New products: from an idea to a running application

Start a product with no code, grant access step by step, and deploy each environment when a person you named approves.

A new product starts with no code at all. You choose how it is built and where it runs; Yavaren creates an empty repository, opens a set-up pull request with the application, its infrastructure and its pipeline, and deploys through your own pipeline. A person in your team decides at every risky step.

Start a new product

Open Requirements and choose New product. The wizard asks, one step at a time:

1. Product: its name, the project, and a tracker item if you have one. Documents are added on the requirement's page afterwards.
2. Stacks: the application's language and framework. Each choice has a short guide.
3. Repository: where the new repository goes on your repository host, whether it is private, its main branch, and how many reviews a pull request needs.
4. CI/CD: the pipeline system. The recommended one is your repository host's own.
5. Where it runs: Azure, AWS, Google Cloud, a Kubernetes cluster (in your data centre or a cloud), or your own Linux or Windows servers. For a cloud you give the subscription, account or project and the region.
6. Environments: dev, staging and production, their addresses, and whether dev is deployed on every merge (off unless you choose it).
7. Approvers: the people who decide for this product: the brief, the features, the stories, the set-up pull request and every deployment. Only they can.

Each step shows the recommended choice. You can change the plan until the repository has been created; after that only environments and approvers can change.

Grant access

The requirement's page shows a checklist made for your choices: the repository host, the pipeline system, your cloud's trust for the pipeline (no stored cloud key where the cloud allows it), the cluster or servers, the container registry, and optionally a domain. Each item explains what to create, with the least access that works, and gives commands you can copy.

You never enter a password, key or token here. You store it in your organisation's secret store and enter only its name. Yavaren refuses anything that looks like a secret value.

Verify runs a read-only check on your own runner and tells you in plain words what it found, for example "the role trusts exactly the expected identities" or "this host's key is not in the list you gave". Some things cannot be checked from outside (a pull agent on your servers, for instance); an approver confirms those. The requirement waits until every required item is verified or confirmed.

The repository and the set-up pull request

Yavaren creates the repository only if it does not exist, or if it holds nothing but a README, a licence or ignore files. A repository with code in it is never touched: the step stops and says which files it found. Yavaren then adds the environments, opens the set-up pull request as a draft, and protects the main branch so changes need a review. A person in your team reviews and merges it. Yavaren never merges.

Deploy

After the set-up pull request is merged, the page offers Deploy to dev, Deploy to staging and Deploy to production. When an approver you named approves, Yavaren starts your own pipeline for that environment and follows it. Your pipeline system's own environment approvals still apply. The deployment runs in your pipeline, in your environment, with your identity.

The page then shows the pipeline run, the deployed address, or the step that failed, with the job's log. If a run is still going, Check again follows it again. Go back deploys the previous successful version of that environment, approved in the same way.

Your own servers

For Linux or Windows servers you choose how deployments arrive. With SSH, the pipeline connects as a deploy user that is not an administrator, and only to hosts whose keys you listed. With the pull agent, nothing connects to your servers: each server checks the registry and updates itself. Applications run with Docker Compose, as system services on Linux, or as a Windows service.

Where the work runs

The checks, the repository set-up and the deployments run on your runners like any other work, in your cloud or your data centre. Nothing needs to reach into your network.