How to deplot small projects?

the philosophical questions you have, you can take hours of discussion

A full CI/CD to raise not see the point given the size

well you're still some scripts to stir and Choteau to invent
what a difference this will cron scripts on the server or job in Jenkins? for speed of writing - is the same. so I think the size here doesn't matter
the only thing that matters is how clearly you have described a process(algorithm) of the build/deploy applications
from this point of view, my vision is something like:

1) git is not the tool for deployment, git only for versioning code
and the idea the result of your work should be no code in github, and some sane artifact ready to deploy (docker-image, pip package, npm package, deb package, jar, war, zip in a pinch, etc). If to produce artifacts the question of the tags will disappear by itself - you will have the artifact one version and all
the server should not know about Gita nor about any tags in it
Here I would recommend packing everything in Docker, image if only because the server eventually will not know anything about the application dependencies, required libraries, nothing at all, you need to only install Docker
A huge advantage of using Docker in Dockerfile you are forced, Willy/nilly to describe accurately and clearly all the steps required to install the application. And best of all - it will all be stored in the same repository, under control of git - chic.
Artifacts should be stored in some kind of artifactory,
but if you really simple - you can keep several of the latest versions directly on the server or something and daddy

2) once you've got an artifact - it can be deploie
it would know the characteristics of your project, but roughly speaking say that it is enough to naplodili on the server, put in the right place
again with this Jenkins will handle great and will take you it's all a matter of 10 minutes . If you describe the logic in Jenkinsfile you win again because the deployment process(the algorithm) will be described again EXPLICITLY. And will also be under the control of the Gita. (Jenkins only needs to know what repositories and where to look for Jenkinsfile)
If you're going to turn some hidden cron script on the server about him to anyone, nothing is known. Believe me after a short time the whole thing will start to get complicated, something forgotten, something changed and it all together will hurt you in the balls.

What is the advantage of this approach: if you need to do a roll-back to previous version you do not need to build the project again deflating all with the Gita, because you have previous artifacts, rollback in this case, no problem - just define the previous version of the artifact and deploy again and all the

3) Env Variables
when the application starts: reads all he needs from the environment variables
deploy job can every time these variables are set before deplot - it would also be cool because you would make this knowledge explicit as well

Total we have
- the logic of building the project are described in the Dockerfile and is under git
- the logic of deployment is Jenkinsfile and is under the git, and most importantly is the code (Jenkinsfile write in Groovy, for simple things you'll need 30 minutes of studying and all)
- on the server we didn't set quite apart from the Docker
- we store multiple versions of our app just in case, and can quickly roll back without having to Gita at all
server does not know anything about gitah
- on the server there is no additional logic in the deployment of your application
- having all it's very easy to add more servers for deployment - what we need - roughly speaking, to specify a different IP and set env variables to it ( if they are different of course)

1. Is it a good idea to pull everything solely on the tags i.e. I put on the front and on the Beck tag v0.4 and the script on the server pulled both
2. Samonadeyanny the script is constantly cecause tags Galaba it's generally a good idea? What +\\- deploy tags?

Labels can be put. Even good releases marks to note. You can always determine which komit need to revert to locally recover the version code as on the server. And release notice to write at the git log between tags, not in memory keep.

Constantly cecati git is not necessary. Extra burden on Prots. Completely unnecessary. Recommend web hooks or deplot SSH command.

3. What addresses and ports.

Pass in the configuration files or environment settings

10+ variants on the page https://css-tricks.com/deployment/
I for different size of projects used
1. deployhq - as soon as updated the master branch - service updates to the server via SSH
2. web hooks from bitbacket + samopisny web PHP script without timelimit - as soon as the hook comes about updating the master branch, a script like this

cd /var/www/project cp web/closed.bak web/closed.html # close the app git pull composer update && php yii migrate # as the code buck upgrade npm run build # as the code to update the front rm web/closed.html # to open the app

3. the same command executed via ssh, no web hooks. It when needed from back and front to rebuild from a different repo and from different branches. What type of demo from develop branch, and releases from the master branch on multiple servers.
4. set up Jenkins for auto-installation

Basically satisfied

3. You have to have separate configs under the prod, test and dev machine.
1. The normal idea. Plus the fact that the use of a name tag is clearer than the hash of the commit.

1. maybe, but don't see the point.
2. why?
3. to do separate configs in different files.

My offer - to have to deploy a separate branch. Once convinced that all works - marisi in a combat branch changes. On Gita webhook catches it and runs a script(say a combat branch - master):
To connect to the combat server for ssl and runs the command:
git fetch --all
git reser --hard origin/master
further, the taste of migration, etc. and etc. Simple, cheap, cheerful. Change is

Once you work in Networks, then you already have the tool for the organization of CI/CD.

1. Is it a good idea to pull everything solely on the tags i.e. I put on the front and on the Beck tag v0.4 and the script on the server pulled both

No, it is not obvious and will complicate the work if the turnips are different, and the versioning they should be different. If you need the latest version, pull from master. And to upgrade a plug-in FOR external use specialized programs (the same composer in php).

2. Samonadeyanny the script is constantly cecause tags Galaba it's generally a good idea? What +\\- deploy tags?

Why constantly cecati? In Networks there are hooks, if you need some actions to carry out on push.

3. What addresses and ports. For example, in index.js on development machine I have written the windows.base_url = "localhost:1234" and the server I need "10.1.2.6:9000" how to automate?

All settings should be in the config file when you deploy configuration is adjusted depending on the environment. You can make different files for each environment, but still something will have to change the config in the Assembly (for example, passwords to the database you will not keep in repository).

Enjoy free CI networks, is mounted on the end car networks runner and tied to the project, describe the project and deploy in the form of a yaml file, which is put into the root. It is very convenient and easy way.

Stanislav Pugachev, in my view, described the current best solution. However, if you do not want to mess with Docker, you can read this article