How to properly build the development process?

Question

git

Hello!
There are 3 servers.

1 - production. Battle server.
2 - test. We show the client intermediate results.
3-dev. We develop new features.
..and also a repository on bitbucket that I work with through sourcetree.
How to properly implement such a workflow?
I write code in the IDE, gulp builds the frontend, everything auto-deploys to the dev server, I look there. There is some intermediate result. (conditionally: we make a news block, done adding and reading news)
We make a commit to the dev branch. After that, we automatically deploy from the git to the test server.
Then we made new functionality with such commits (deleting, adding, moderating, reading, editing news).
All checked, everything works. We send all commits from dev to production. We automatically uploaded the latest version from the git to the combat server.
What tools might be needed to implement such a system?
Am I correct about this process?
How to implement it?
Thank you in advance)

Answer 1

What tools might be needed to implement such a system?

The question is probably not entirely relevant. They may list the tools you need to build a house, but this will not help you build a house. But, not to be unfounded, you will need:
1. Git server (Bitbucket, Gitlab, etc). If you work alone or the project is very simple, then gitolite will be enough.
2. CI server (Bamboo, Jenkins, etc).
3. Any programming language for writing pre-receive/post-receive hooks and tasks for CI.
Regardless of whether you work alone or in a team, from my point of view, the process looks complicated and far-fetched. I would start with a simple process and only get more complicated as problems arise. If you start with a difficult one, you will immediately create problems for yourself. And you will create new ones by solving old ones.
As I see it, a simple process:
1. Take one branch that will be stable, for example, master.
2. For each feature, create a separate branch from the stable one. For example, ivan-news-block or ivan-search-bug-fix. You can come up with any rules for naming.
3. Test the code on your virtual machine. Regular vagrant + virtualbox. If you add a second developer, then he simply takes the Vagrantfile and a virtual machine with a ready-made environment for work appears on his machine. Why do you need a shared dev server?
4. The deployment process is controlled either by the CI server, or ansible / puppet, or self-written scripts.
5. When the branch is ready for release, then start the deployment process to the test bench, where you can show it to the customer or someone else. In the same place CI can run tests.
6. When the feature is approved by the customer or the software of the task, then start the deployment process for the battle.
The question clearly needs clarification. Now your question is: "How to draw an owl?".
But I can recommend something:
You need to start by building a process with doing all the actions manually. Then gradually transfer each manual operation to automation. Do not immediately try to make some perfect mechanism.

Answer 2

Almost. Instead of
we roll this functionality from dev to the main branch (master), into production only with the main one.
For the test, we send only what is ready for transfer to conditional testers.
gitflow for different people.
something like gitlab+jenkins is enough

Answer 3

sourcetree is buggy in the latest version and has been completely phased out in the last two weeks.
so take hg / git flow , there will be a branch for production (deployed to production), for the latest development versions, develop a branch that deploys to test, well, a branch for each feature that each developer develops on his dev server, when he finishes, he closes the branch features and it is merged into the develop branch and automatically deployed to the test server. When on the test server we see that the sane dev branch merges into the master and the master is deployed to the production server.
google hg/git flow