We are using before_release and I wanted to ask a question about the order of operations. When the before_release finishes, in our case a migration, are the new containers already ready and switched over to? Or do the new containers launch after and there is some time that the old containers are using the new migration?
The operation prepares to launch the new containers, e.g. by scheduling where the new containers will be launched and pulling the App’s image on those instances, so that they can be started as quickly as possible but it doesn’t stop or start any containers until after the before_release commands finish successfully. This does mean that the old containers are still running after the new migrations have been applied which is why we reccommend that migrations be backward-compatible with the current Release (i.e. the old containers). If they aren’t then most of the time the worst that will happen is that the old containers will throw errors but, depending on how the application and migrations are architected, they could make breaking changes to the Database.
If you’d prefer to avoid having the old containers interact with the Database after the migrations have been applied, there are many ways you could go about doing so. One of the more simple solutions is to scale down your Services that use the Database to zero containers, deploy, then scale the services back up. However, you would lose most of the benefits of Aptible’s release process such as automatic rollbacks with this approach.
A more complicated solution would be to store the current release/migration version in the Database and the App and have the App containers check this against the version it’s compatible with before interacting with the Database or, using Strict Health Checks, it could report to the Endpoint that it’s unhealthy when it’s not compatible. Utilizing health checks would cause the Endpoint to show the App’s Maintencance Page between the time the migration is applied and the new containers are available.