How to make a quick rollout to production?

Question

Programming

Colleagues, good Sunday everyone.
Who decides how to roll out new releases (code and | or database) into a live project?
We use git now, but merge conflicts are very slow and users are not good :(
Yes, and we constantly have to do export / import.
Thank you all for the answers.

Answer 1

merge conflicts are very slow

1) Split tasks, make branches short-lived
2) It's a good idea to rebase accepted branches
3) Try adapting git-flow for yourself, feature-toggles instead of feature-branches works well as an alternative
1) Migrations
2) Try to make migrations in such a way that they do not break previous releases. Well, if you need to add a column, it would be a good idea to make it nullable in the first release so that the old version of the application can still work with the new version of the database, and then finish off this piece with the next release. The main idea is that it is desirable that the two latest versions of the application can work with the latest version of the database. If your base is normalized normally, then there should be no problems with this.
If the second point is observed, then the rolling of new releases will occur according to the following algorithm:
- a new build of the application is rolled out to a separate directory (you can automate, organize the rotation of builds, etc.)
- we roll migrations to the base, in this case the old version of the application will work with the already new base structure
- we switch webroot to the new version. In the case of containers (docker), we extinguish the old container
- if something goes wrong, we can quickly change the symlink back and start the migration rollback
. In this scenario, the downtime will be minimal.
Here are the options in order of difficulty and power (from simple to complex).
- capistrano/capifony
- ansible/puppet/chief/etc
- docker + docker-machines + docker-compose
Well, yes, tests tests tests. All the most critical should be covered at least by integration/functional tests. Ideally, all business logic should be covered by fast unit tests and functional UI / infrastructure (read about the testing pyramid).

Answer 2

> We use git now, but merging conflicts are very slow and users are not good :(
Judging by this phrase, you are doing something wrong.
Are you doing merging directly on the production machine? Otherwise, how do users know you had conflicts merge, or not?
Do you have a test environment where you push a branch before it goes into production? If not, be sure to implement.
Do you have automated testing? If not, implement at least basic smok tests.