Skip to main content

Bootstrap

Here we describe how to can start new Devotion projects.


New pure API project​

Project creation​

To bootstrap within an existing Git project:

# ./my-new-api could already contain a .git directory, after a git cloning for instance
cd ./my-new-api 

# Then, we can bootstrap right here with this:
aldev bootstrap -n MyNewApi -w --destination .
info

We can also bootstrap the project and git-init it right away:

cd $GITPRIV
aldev bootstrap -n MyNewApi -w --repo my-git.domain.com --group group-name[/subgroup]

# this creates and push the new project to https://my-git.domain.com/group-name[/subgroup]

The Go API code is in the /api folder.


top

Working with the new API​

First, go into the project: cd my-new-api.

Then, for the aldev command to work, its config, the .aldev.yaml file, should be filled up / completed.

Once the config (.aldev.yaml) is set up, we run the API server with just:

aldev

Or, if you want more details about what's under the hood:

aldev -v
# or
aldev --verbose

You can learn more about aldev later, but what you can at least see from the logs is that it created 3 instances of your new API + a load balancer (Nginx) in front of them.

Which can be confirmed by checking with this:

podman ps

info

Don't git-push anything just yet, we'll need to do it later on, at the deployment stage.


note

As you'll learn later on, aldev generates config files, for local building & testing, as well as remote deployment. Depending on the configured deployment platform and CI/CD method, it might require for the project to be git-initialized - which is automatically the case if you've used aldev bootstrap with the --repo arg.


top

Developing & testing the API​

You can start modifying the Go code in the /api folder while aldev is running.

More details about how it's architectured in the Goald documentation.

As soon as you save your changes, aldev will perform automatic operations, and locally re-deploy the updated server's instances.

You guessed it...

This allows for quick dev & test iterations.


top

Testing the API​

To test, do this in another terminal window:

# adapt the port to what's actually configured
curl http://localhost:42069/rest/translation/fr\?Namespace\=Common

This should return a JSON response with translations.

info

If you repeat this request several times, you'll see in aldev's log that the load balancing is effective.


top

Deploying​

Handled platforms​

Depending on what's configured in the .aldev.yaml file, CI/CD and infrastructure management can be assisted by aldev.

In particular:

  • the config item deploying > platform influences what files (e.g. Terraform configs) aldev generates to help with infra
  • the config item deploying > cicd influences what files (form instance: .gitlab-ci.yml) aldev generates to help with CI/CD

For now:

  • only the value "azure" for deploying > platform has an effect: it triggers the creation of Terraform Azure configs in the deploy/remote folder
  • only the value "gitlab" for deploying > cicd, in conjonction with deploying > platform = azure has an effect: it triggers the creation of a .gitlab-ci.yml file, which helps continuously deploying to Azure

Learn more here about Gitlab CI/CD + Azure deployment.

info

As of now, the aldev-generated .gitlab-ci.yml and Terraform files already help us continuously develop & deploy to Azure.

Learn how to use it here.

top