Deployment Stage Setup, Improved Deployment Time in Case of Failure, [Terraform Provider] Improvements...

Hi there, fellow changelog reader; today marks a big milestone in our changelog history because we reached the number 30! As much as we love this format, and we know you love it too, we decided to introduce a novelty in our changelog. I joined forces with Benjamin, Backend Engineer that will give you more insights about what’s happening in the background that makes your cluster work. Without further ado, here is the changelog.

#Deployment Stage Setup

Already started during the last sprint, you can now create and drag & drop stages; for more information, look at the Deployment Pipeline documentation.

#Improved Deployment Time in Case of Failure

The timeout used to be automatic, which caused a long wait in case of failure but it changed and it’s now adjusted depending on several parameters (e.g.: number of instances); this change helped reduce the deployment time in case of failure significantly.

#[Terraform Provider] Improvements

Our Terraform provider is not perfect (yet), and we are working hard to make it as good as the interface; during the last sprint, our team worked on adding Advanced Setting for the cluster and better instance support for AWS and Scaleway.

#Nginx Logs View

Available only with at least one declared port, this option in the application logs is here to help you debut; for more information about the logs format of Nginx, look at this documentation.

#Billing & Plans V3

The last remaining block to make the V3 completely ready was the billing and plans part, and this part is now complete; you can now view the details of your plans and add your billing details straight from the V3 interface.

#Killing of V2

After adding the Billing and Plans our V3 console which was launched in Alpha testing in the summer and in Beta around the end of September was finally ready, and so on the 15th of march, we did our last goodbye to the V2, meaning that the URL new.console.qovery.com is not used anymore as a redirect is now made to console.qovery.com.

#Smaller Improvements and Fixes

• Bug - Added Cancel Deleting Action for Button Actions
• ANSI Format in the Deployments and Application Logs added; more information here

#What Did the Engineering Team Do Without You Noticing 🪄

Support ARM architectures: best price performances for a lot of workloads

• Work in progress adding ARM support to Qovery stack(cert-manager-webhook, external-dns, qovery-agent)
• Qovery Engine to support multi-arch builds allowing Qovery to build any application targeting ARM architectures

Container images management improvements:

• Improve remote images existence check using buildx imagetools inspect : avoid to re-build locally an image already built on the registry
• Upgrade debian images for all our applications: support all security updates & bug fixes
• Move Docker builder out of Qovery engine process: the builder part being the one needing the more resources to run (min 4Go of RAM), moving it out of the Engine allows Engine and Builder to scale independently avoiding to waste any resources
• Moving to our own ECR public repository: avoiding DockerHub issues such as missing images, etc... enhancing reliability

Misc

• Upgrade containered Redis images versions: support all security updates & bug fixes
• Upgrade containered Postgres images versions: support all security updates & bug fixes
• Upgrade containered MySql images versions: support all security updates & bug fixes
• Add newly added AWS and Scaleway instances types: being able to create clusters using latest supported instances

Best forum topic of the sprint:

• Struggling to get a successful deployement on the first deployement
• Mutualizing Load Balancers
• Prisma issue with DEFAULT_DATABASE_NAME 'mysql' on mysql database
• Kubernetes cluster version updated on AWS but not Qovery