software engineering: reducing risks and issues when deploying on production

 

>PROBLEM

While developing an application, you have worked using local env(environment), using your local database or cloud resources of your own.

Then, it comes the time when you need to deploy to production or another job's env.
It is the moment that may happen the usual setbacks, issues showing differences among the job's env versus your local env.

The question is:

How may you reduce the issues when deploying on another env?

>SOLUTION

The full evaluation of all possibilities is impossible, so I'll offer you an example, and  by analogy you may apply to yours.

One very trivial item from our checklist is the resources closing, like files and database connections.
This example uses PostgreSQL database and the connections issues.

In our checklist we may have these two basic items:

1- How does the job's database env differ from my local database?
2- How to test my application to make sure that all resources are really closed when it is terminated?

Solving item 2 - Is your app functioning well?

First, make sure that your application is closing all resources.
For instance, if using PostgreSQL, do:

a - Before starting the app, run:

SELECT sum(numbackends) FROM pg_stat_database;
The cmd returns the number of busy connections, for example: 8

b - Start your app and run some features.

c - Repeat step "a".
Take note.

d - Close the app and repeat step 'a'.

e - Compare de results.

NOTE: try to do this during periods the database hasn't an intense usage because the usage fluctuation may interfere and you have to do some guessing, but you may be lucky if you perform the test when no other new outside connection occurs among the procedures. Choose a proper time when your team is out, or not working with the resource.

Solving item 1 - How does the job's configuration differ from yours?

Considering that you have no access to the configurations of your job's database, as usual, do this:

Choose a moment when your job's database resource has little activity.

Start your app, then close it abruptly, forcing it to terminate without closing your database resources.

Repeat it many times until you the connection to the database is denied, but counting.
The denial is easy to check using DBeaver, DBSchema, PgAdmin, etc.

If your database denies access, you have two possibilities:

Or your job's configuration is restrictive or poor.

A restrictive configuration limits on purpose the number of available connections.

The poor configuration just happens to go as it is without further knowledge of the guy who did it.

After the test, it is recommended that you create another local database having the same restriction of your job's configuration. That way, you'll have one problem less when deploying to the job's env.

>ENV

PostgreSQL (any database)
Any application.