Environment Lifecycle
In order to fully understand how the Artifakt platform works, it is essential to have a good understanding of the life cycle associated with the environment.
When you create an environment, you will need to define its criticality. Usually, our users define their production environments as
critical (business-critical applications) and their testing and development environments as noncritical (non-business critical applications).Depending on your choice, some features will become available for that specific environment.
Feature | Noncritical environment | Critical environment |
Environment monitoring (health check) | No | Yes |
Highly available database | No | Yes |
Retention of database backups | 1 day | 7 days |
24/7 support for production incidents | No | Yes |
Yes | No |
Criticality also affects the cost of an environment. As a consequence, adding up advanced features on a critical environment will lead to an additional cost that should not be overlooked.
To create an environment, go to the desired project and click on New Environment.
You must then define some important information:
Create an environment
- The environment name
When you create an environment, its general status is
Not built. The environment does exist in the Artifakt Console but is not yet deployed and available online. At this stage, no Cloud resources have been created yet.To make the environment accessible online, you need to start building the cloud platform. To do this, go to the desired project and click Start in the drop-down menu of the desired environment.
Start an environment
The general status of this infrastructure then changes to
Building, which means that the cloud resources of the platform are being created.Please note that when building the environment, a first code deployment is automatically performed.
Building time varies according to the selected platform type:
- Starter – approx. 5 min
- Scalable – between 35 and 45 min
When the construction is successfully completed, the general status of the infrastructure will change to
Built, which means that the Cloud platform has been successfully created. You will then have to deploy the application source code when you are ready.Duplicating an environment allows you to quickly create a copy of an existing environment and keep the same settings.
When duplicating, you can adjust a few settings including:
- The environment name
- The Git branch to use for code deployment
- The Custom configuration (JSON)
If you duplicate an environment already deployed online (with
Built status), the copy will not be deployed until you start building it. In other words, a duplicated environment is always Not built by default.When an environment is
Built, you can destroy it by clicking Destroy in the drop-down menu of the desired environment. The Cloud platform associated with the environment will then be destroyed and the environment will return to Not built.
Destroy an environment
At this point, you can then completely delete the environment from the Artifakt Console by clicking Delete in the drop-down menu of the desired environment.
Delete an environment
The difference between destruction and deletion exists for practical reasons. You can destroy an environment today and rebuild it the next day without having to re-create it entirely in Artifakt or configure it again according to your needs. Deleting a destroyed environment will remove it entirely (including configuration) from the console.
The Operating Schedule allows for automatic shutdown and startup of the main servers of your environments depending on a provided schedule. This can be found in Environment Settings > General.
Operating Schedule
Start Date and Start Time specify the moment when the main servers are going to start. End Date and End Time specify when the main servers are going to shutdown. Opening days allow for a weekly schedule to be configured, making the platform run only on selected week days.
Please be careful when setting up the Operating Schedule on production environments as misconfiguring it can shutdown the main servers immediately and cause downtime.
Example : Setting up a schedule for a dev platform
If you want to setup an automatic shutdown at the end of business hours and on weekends, you should configure the Operating Schedule this way :
Example of a dev platform schedule
This will effectively start the main servers on the Opening Days at 7.30AM and shut them down at 7.30PM. This also means that the main servers are going to be shut down Friday at 7.30PM and stay in sleep mode until Monday 7.30AM.
You can also only set up Opening days without any times, making the platform shutdown at midnight on the end of the last day and start at midnight on the beginning of the first day.
Each environment can have 2 statuses :
- The "general infrastructure status" reflects the state of the associated underlying Cloud platform (the infrastructure).
- The "environment status" reflects the state of your application. This status is displayed only when the Global Infrastructure Status is "Built" or "Updating".
General infrastructure status transition
Status | Description |
Not built | The platform is not deployed online (no Cloud resource created). |
Building | The platform is under construction (Cloud resources are being created). |
Updating | The platform is being updated (changing sizing, adding / removing services, etc.). |
Built | The platform is deployed online (Cloud resources have been created). |
Destroying | The platform is being destroyed (Cloud resources are being deleted). |
Error |
Environment status
Text | Description |
|---|---|
Running | The environment is running. |
Paused | The environment is stopped according to the configured operating schedule. |
Last modified 9mo ago