Is it ok to keep a copy of the repository on the host?

Question

git

I'm used to the fact that this is convenient: I put a copy of the repository in production and do a git pull if necessary. I write in Python and Ruby, so I don’t need to compile anything separately: the hosting has the same sources as on the home machine. And the distributed version control system also works as a project deployment system. Bonus: if my commit failed some functionality and the tests did not reveal this, then you can always roll back to any other version of the code without additional tools.
If some kind of extreme situation has occurred and changes have been made to the code on the server (past version control), then it is easy to track them and even commit directly from there (although, I think this is wrong).
What are the disadvantages of such an approach?
It is clear that there are special tools for project deployment. It is clear that they are convenient and necessary when working with Java, for example. But I do not see how git and hg are inferior to them in this regard, if the development is in an interpreted language.
I understand that once someone compiled a bunch of sources from .svn directories openly lying in the web space, and now all VCS on the server are considered something bad. But you have to understand the difference...

Answer 1

I also sometimes practice this (when it is justified by saving time with low risk)
Some thoughts:
1. And if an attacker gets into the server and gets write permissions to the Git repository, he will be able to destroy it - apparently yes stackoverflow.com/questions/2006172/how- to-reset-a-remote-git-repository-to-remove-all-revisions
2. You can roll back to the previous revision in normal deployment systems (sometimes a symlink is placed on a specific revision).
3. You need to remember to make sure that the .git folder was not accessible from the web
4. Deployment systems can do much more complex things - restart server processes one at a time, use custom deployment scripts, perform database migrations, track deployment errors. And here you have to do everything yourself with your system.

Answer 2

It is necessary to separate the concept of source code and deployed application. When it seems to be the same thing, it seems that you can use the version control system for deployment. But in general, the version control system was invented to control versions and not to deploy.
That is, conceptually, this approach is wrong.
The smells of this problem will manifest themselves, for example, as follows: some data will end up in production, although it should not be there (code for tests, for example).
The bonuses and advantages of the approach you have listed are not actually any bonuses or advantages - specialized deployment systems allow you to do all this.
In addition, they still allow dofig just.
For example, automated uploading of the application to the test circuit after check-ins, running long-term tests, collecting code metrics, tracking the history of deployments, testing, etc. Instant signaling of any problems with the solution (like the downfall of the entire build or test) to all team members and much much more.
Of course, something can be done with version control hooks - but this is actually scratching the heel of the ear.
And the point here is not at all whether the project is in scripting languages ​​or not.
The question is whether this is a serious decision or a craft on the knee.
As soon as your project reaches a certain level (if it happens), then you will have to use specialized deployment solutions and you will see the need for them.
Until you see a need for them - do not worry and use what you are used to.

Answer 3

This is a normal situation, "I've done this 100 times." Moreover, if you use a distributed version control system (the most popular representatives of DVCS are git, hg and bzr), then each project member has a copy of the repository, so you get a backup copy of the code as a bonus.

Answer 4

do not be afraid that internal passwords, data deleted from the repository, etc. fall into the hands of an attacker?

Answer 5

It's fine if you don't need to restart something or upload it to more than one host.
But, believe me, it takes 15 minutes to set up capistrano once for the rails. Rolling out the code itself is usually only 10% of the deployment task, you also need to 1) update dependencies 2) roll migrations 3) restart unicorn/passenger. If you work more than one, you don’t need to explain to everyone where and how the code is laid out, which is also quite a big plus