SOC 2, Deployment Logs, Parallelize Builds and Deployments...
Hi everyone, and welcome to Changelog 32! I'm excited to share some great news with you. We recently achieved SOC2 Type I compliance, demonstrating our unwavering commitment to keeping your data safe. And we've done some work on our deployment logs, allowing us to introduce a new parallel service deployment feature. But wait, there's more! Keep reading to learn about our container DB logs, API token management, and more! 🌞
#SOC 2
Service Organization Control (SOC) 2 is an auditing procedure that validates a service organization's controls for maintaining user data's security, availability, processing integrity, confidentiality, and privacy. It is one of the most sought-after and rigorous compliance standards in the technology industry, providing an independent third-party assessment of an organization's internal controls and procedures.
By achieving SOC2 Type I compliance, Qovery has been independently verified to have the necessary controls and processes to protect our client's data. This milestone is a testament to the robustness of our security practices and our dedication to maintaining the trust of our clients.
For more information, check out our announcement about it.
#Deployment Logs
With the implementation of the parallelization for the build and deployment operations (i.e. we will parallelize and thus speed up your deployments), we had to work as well on a new Log interface capable of giving you a clean and nice view of what is happening during the deployment of your environments.
Every time a deployment is triggered, Qovery provides you with the log of its execution and as well with any error that might occur. Note: As of now, Qovery can provide you only the log of the latest deployment execution, more information on the documentation.
#Parallelize Builds and Deployments
Thanks to the work we have done on the New Logs view and the Deployment Pipeline, we are now able to announce a new major feature: We have just rolled out the parallel service deployment, a fantastic new feature designed to make your deployments super fast! Before the release, every deployment operation was done sequentially; with this new feature, you can parallelize these operations and deploy up to 4 apps at once per stage. In short, this could make your deployment speed 2.5x faster on average. To read all the details, head to this forum thread; otherwise, you can find the feature in action below.
#Container DB Logs
Another addition to this V3 version is the container DB logs, so you can simply debug your database by yourself.
#Token API
You can now access the token API configuration by opening the Token API section within the organization settings. API token allows third-party applications or script to access your organization via the Qovery API (CI/CD, Terraform script, Pulumi etc..).
You can manage the API tokens attached to your organization directly from the Qovery console.
For more information, check out our documentation!
#AWS Configuration & Managed Database Warnings
This warning is just a reminder that the Qovery team manages your Kubernetes cluster's upgrade, and you don't have to think about it. Upgrades from one minor Kubernetes version to another require a good amount of tests to make sure everything goes smoothly with zero interruptions for your app. Do not manually update or upgrade them on the cloud provider console and the same goes for the managed database, otherwise you will risk a drift in the configuration. Here are more details.
#Jobs Supported in our Terraform Provider
As said during the last two Changelogs, we are working hard to make our Terraform Provider as good as the interface. For the ones using it, I have the pleasure of announcing that Jobs are now available on the Terraform Provider as well.
#Smaller improvements and fixes
- New deployment status - Build error
- Specify the entry point and argument for the git application.
- Using image of CLI so you don’t need to download it locally.
#What Did the Engineering Team Do Without You Noticing 🪄
- Delete all node groups before the first installation: making sure a cluster can be properly deployed even if the previous install led to a failing node group.
- Preparing for 1.24 upgrade: all helm charts are now compatible with 1.24; the next step is to test 1.24 clusters with the Qovery stack.
- AWS S3 ACL fix: There was an issue with some AWS regions making the cluster deployment impossible.
Best forum topics and blogs of the sprint: