Skip to main content

Creating a new application

Either if you want to start a new application from scratch or if you are migrating an existing application to nullplatform, you have to create a new application. To create new application from the home of your namespace by clicking on the Create Application button.

When you create a new application, you can create a new repository or import an existing one. In any of these cases, nullplatform will interact with your repository provider (Github, Gitlab, Azure Devops, etc.) to:

  • (new repositories only) create the repository using the selected template
  • (new and imported) add an API key that you can use in your CI workflows to push assets, builds, releases and metadata

How repositories are named​

When you're creating a new application from scratch we'll create a new repository following this convention: https://my-git-provider/my-organization/${namespace-slug}-${application-slug}.

Setting my own patterns and replacement for a template​

You can further control how the repository name is built by specifying the application_name and repository_path variables like this:

PATCH /template/1234
{
   "rules": {
      "application_name": "^(.*)-api$",
      "repository_path": "s/^(.*)-(.*)$/${namespace.slug}/${2}/golang/${1}/g"
  }
}

By specifying these fields, you can craft the conventions for your repositories in a more precise way.

Example. We have a Golang application named 'transactions-api' under the namespace 'Wallet' and we want it to be named mygit.com/wallet/api/golang/transactions. If we don't do any customization, the repository name would be wallet-transactions-api, but to get the desired repository name, we would need to alter the Golang template setting the field repository_path as s/^(.*)-(.*)$/${namespace.slug}/${2}/golang/${1}/g.

What is a slug?¬Ò

Names can be 'complex' and have characters that might the troublesome for some context (eg: apostrophes), so we map those names to a simpler version called 'slug'. So an application named John's app! will be mapped to johns-app.

If you're also deploying this new application, we will create a default scope named Main.

Continuous Integration​

Any application created from a nullplatform template is already set up with a working CI pipeline that will build, test, and upload the assets to the right location for deployment (eg: Docker images in case of server instances, zip packages in case of serverless functions).

While we recommend not altering the CI pipeline and maintaining it as simple as possible, you can change it in any way you want as long as you keep the steps that communicate with nullplatform and with the cloud provider.

Importing an existing repository​

If you're migrating an existing codebase, you'll want to create a new application by importing an existing repository.

In this case you will enter the repository name and we will automatically:

  1. Create the application in nullplatform
  2. Inject the required secrets on your repository for you to be able to set up the CI pipeline
Create a branch for your new CI pipeline

When migrating an application consider creating a new branch where you can test your new CI pipeline without disturbing the main branch where production code resides.

Once the application has been created on nullplatform, you will have to:

  1. Adapt your CI pipeline to deliver the assets to the right location. You can read about nullplatform CI/CD integration here
  2. (Server-based Applications) Make sure the application is listening on port 8080 and that it is returning a 200 OK status code for the health url (the default is /health).

Once you start committing to your application, you'll be able to see the builds on the Build section of your application's dashboard.