Scheme of CI building and publishing projects, right?

Question

Software Deployment

Tell me how correctly I understand the CI scheme, given that it is simply not realistic to introduce tests into the process at the moment, but there is a very acute shortage in the normal deployment of work results.
Now, deployment and development, brr, such a folder on the dev server, everything works in it (> _ <), well, they roll out files with edits by hand, the end.
But with all this, it is possible to put all projects into git and divide them into the necessary branches (prod, dev, stable), transfer everyone to local development, set up jenkins, but so far, alas, without tests.
So far, I understand the scheme of how delivery from dev to production works like this:
1. The developer copies the project from the git (dev branch)
2. Conducts local development
2.1 Makes a local commit
2.2 Completing the task, pushes to the development branch
2.2.1 Closes it in the tracker like this
3. Jenkins builds the project from the dev branch
3.1 After a successful build, publishes the project to the development server
4. After a successful build, publishes the assembly to the local access to the dev server
4.1 Notifies of the publication builds
4.2 Sends the build to the stable branch of the git (manual control and further here?) 5. After pushing to the git ,
jenkins builds the project from the stable branch
5.1 Sending the built version to production
make a plan of action?

Answer 1

If you're all messing around in the same folder for development, then you not only have problems with CI \ CD, but also with the team development culture in general.
I think you can start with a simpler scheme so that people in the team get used to it, understand how collective development is improving, and then you need to start adding additional features to the required working minimum.
Only without an extra overhead, because it's easy to get carried away with all the modern trendy approaches for a project where it's not really needed.
I will offer you the minimum necessary in my opinion:
1. the project is driven under the git
2. Each developer is allocated a separate dev server, cloned from the sale (it is highly desirable to repeat the production environment). You can deploy vagrants locally, just raise the project locally, but I prefer some kind of remote server pack for development, because often the developers themselves don’t really understand how to properly configure the server and the remote pack of these servers can be easily administrated by your system administrator, and if everything is local for everyone, and even the team is geographically distributed, then this will be a great torment and a waste of time
3. either no one works in the master at all, or some urgent hotfixes are made there. a separate branch is allocated for each task, it is developed in it, and when the development is tested and verified, it merges into the master
4. how the changes to the master were merged - pull the master in production.
everything, this is the most minimal option, where to start, so that people get used to it. as soon as people get used to it and you realize that your developers lack discipline and commit anything to the master for production - make a separate stage branch and stage server. where you will merge developments from feature branches and check there for what you have
developed. if the changes are approved - pour the stage into the master and pull it to production.
When you realize that you are tired of walking and pulling with your hands in production and running all sorts of frontend build scripts and so on, you can go further. start a separate build server (it either always hangs static or for each build you can deploy, for example, a docker container) on which all the software necessary for the build is installed. e.g. all node-modules for front assembly.
And when you push to the master, then jenkins or teamcity or something else sees it, pulls your code to the build server, runs all the build commands and then packs the built code. then comes the deployment time, when the deploy script takes your build to production, unpacks it, and in some way makes it active, instead of the build that you had (this can be switching symlinks, switching docker containers, etc.)
It seems to me that this scheme will last you for a long time. And if this is not enough, you can continue to produce a full set of branches with git-flow. But for this, you must seriously argue their need for yourself.
Perhaps, to understand the CI \ CD scheme, using a specific example, such an article will help antonov-dev.ru/blog/11
There, although it is about Bitrix, it does not change the general idea much

Answer 2

2.2 Finishing the task pushes to the development branch
2.2.1 Closes like this in the tracker

Wrong. The task is closed only when the feature branch is merged into the master. There is a lot of action between these events.
We need to deploy this branch to one of the devboxes and check it out. Run the necessary tests on it, make a review.
And only then die.