A simple but fine development work-flow
In this article, I’m gonna explain a simple but useful workflow for developing. Although as a Python developer my example is with this programming language but also you can integrate it in any language you like and work.
Before getting to this I’m gonna explain what is my Git workflow.
We all know there are many best practices for Git flow but to my experience, I’ve found one of those more useful and working without any strains. It depends on your company scale and development team to choose the best Git-flow but here I’m gonna use a basic yet nice one. (In a separate article I’ll explain some of the Git workflows.)
As you can see the diagram above there are two main branches:
1 — Master
2 — Pre-Production
The master branch uses for pushing the simple development codes. Developers work on the issues (as separate branches) and then do a merge request for merging on the master.
Whenever you are happy with the progress you can do a merge request to the pre-production branch for further testings. I call this the Development Version (D.V). The D.V version is the one in which everyone can see it and it builds on a server. Front-end developers can do the integrations, QA can do the tests and you can demo it to your superiors. Whenever the version in D.V is right now you can create a TAG and it’ll be your Production version/release.
I believe the production version cannot get changed directly and it has to be always versioned. Therefore the tagging would be the solution.
That’s enough for the Git-flow now. Let’s take a look at development work-flow. Some people may call it the CI/CD but I’d like to know it as a work-flow.
Let’s take a look at the diagram below.
Whenever a developer pushes their code there is a certain process run automatically (rather than manual). The codes go into the master branch then it will trigger the CI pipeline to run some basic tests. The CI can do lots of things but I’m gonna focus on the testing part right now. If the tests are passed then it will be ready for merging request, otherwise, the pipeline would be failed and it’ll notify the developer to fix the issue/s.
After the merge-request on the Pre-Production branch, another pipeline runs. This one can build the project and create the image then pushes it in the Gitlab (as my example places there) and prepare for further actions.
the CD part would run much more advanced tests and if it passes then it will be ready for deployment.
The deployment part can be tricky. If you like to do these things automatically there are a couple of ways. But truth be told most of them for me always led to one. Docker API. If you have a server somewhere that has Docker installed you can run the API on them to pull the image and run it. Also, there are a couple of useful systems you can use to achieve this. One of them that I like to use is Portainer. If you wanna pull it on a cloud there are many services like Amazon ECR. Another way is using Terraform to create a new server for example in AWS and pull the code there. So the CD part is up to you and your infrastructure.
There is one part remained and that is Sentry. Sentry is a very useful error tracking system that implements into your code. Sentry can integrate into the Gitlab and all the errors on the pre-production (also in production) would report in the Gitlab panel beautifully. You can review them and make the issue and repeat the whole process.
There are many types of CI/CD and D.V out there. Lots of them can confuse you so that I wanted to reveal a basic one to see it’s not that complicated.
I may try to write a couple more articles about this and demonstrate the execution part later.
As a CTO it’s your job to understand these work-flow and implement them in the development team. Of course, never forget it’s your responsibility to make sure everyone understands it well and they can use it.
Thanks for reading this,
