Toko Distributor: Sebuah Catatan
A little note (a bit technical) on what and how Toko Distributor’s team did until this article is written and its future plan. 👨💻 👩💻
Intro.
“Tak punya tujuan tak apa, berlayar tanpa peta pun tak masalah, asalkan kita bersama-sama”
-Start-Up K-Drama, 2020-
This journey started around mid-September 2019, when I first joined Toko Distributor team as Backend Developer.
Back then, other than adapting to the team and doing main job desc., my other “responsibility” was helping the team to realize that there are some things that need improvements.
In the next chapter, you could find out what we (as a team) did to and how it turned out to be.. We believe, we will have it fixed, somehow, but we are sailing together through the journey to be better.
Software Development 🚲
This area is where we have our daily to-do lists, mostly on Build → Test → Release flow.
Git Flow
Maybe one of the early ‘improvement’ we did, is trying to adopt git flow, here is our version of git flow (combination of git and forking workflow).
Although this improvement seems small, we tried to be consistent following this flow. Recently, we also implement feature branch before MR/PR to development/staging branches.
Git Practices
In our case, many of our development team members are still not yet familiar with git so-called best-practices, so we tried to create our own style of (simpler) git practices.
- Fork & Clone
We urged our development team members to fork the main repository, before starting to code and .. don’t forget to clone to local machine. - Git remote policy
We tried to separate using two remote repos, namely origin and upstream, origin: for local/developer-owned repository -forked result-
upstream: for main repository
by using this kind of approach we tried to ‘simplify’ development process.
$ git remote -v
origin https://gitlab.com/djiwandou1/supplier-repo.git (fetch)
origin https://gitlab.com/djiwandou1/supplier-repo.git (push)
upstream https://gitlab.com/tokodistributor/supplier-repo.git (fetch)
upstream https://gitlab.com/tokodistributor/supplier-repo.git (push)- Git commit message & description
For the purpose of clarity and maintainability, we prefer to follow git commit so-called reference as follows:
Format: "type: Subject"
Type:
feat - fitur baru
fix - bug fix
docs - perubahan dokumentasi, readme, dll
style - semua yang terkait perubahan styling
refactor - perubahan code yang bukan bug fix atau menambah fitur
test - semua yang terkait ke testing, automation, unit test
chore - perubahan konfigurasi, dockerfile, webpack, package manager, dllExamples:
* git commit -m "style: Change style dot pagination"
* git commit -m "chore: Add config example for production"
* git commit -m "feat: Add review page"
- Other git practices
Think of any things that could make our development process more comfortable (for us and others who read our code).
In order to do that, we always try to optimize many git features by following this guidance, for example:
git stash , git cherry-pick , git diff , git rebase , etc.
Code Review
So far, we tried to make all the team members to actively participate in code review process. In our case, we were just getting started from MR-PR from development/staging branch to production/master branch, where everyone needed to check whether their work is it correctly merged, or to check if there are any leftovers or feedbacks. We are on our way to be better together. 💪
In case you are lost on what are things to be reviewed in a code review process, try to look at this: Google Guide on What to Look for in Code Review
Product Development 📦
In this field, we need to admit that we are still lacking of knowledge and practices, but we are striving to find the most suitable ‘evolution’ in this area.
SOP Product Development
We tried to define our methodology and grow it using our experiences and lessons learned, this is the current result, SOP is Standard Operating Procedure in case some of you wonder 🤔
JIRA workflow & tasks
The flow in product development SOP then translated into JIRA, starting from Backlog to Board (To Do → Done).
Our product team also improving by providing clear and easy to understand and to breakdown Definition of Done (DoD). Moreover, the team also needs to ‘communicate’ and collaborate through JIRA for the sake of history and clarity in development process.
Scrum & Agile (Rituals)
We truly hope, we could get the positive values by following rituals first, then realizing the real philosophies behind it and later to instill the values in our behavior and mindset changing.
- Daily stand-up
It is not just a simple meeting, I believe it is one of the most important culture in our team. What items to talk about? see this:
Daily stand-up item:
- Apa yang sudah dilakukan dari stand-up sebelumnya?
- Apa yang akan dilakukan / to do hari ini?
- Ada rencana dari anggota tim lain yang akan overlap/intersect dengan saya?
- Perlu bantuan dari anggota tim lain untuk rencana to do hari ini?- Sprint planning & sprint retrospective
There are many tools to do this, in our case we used JIRA, google meet/zoom and Remote Retro for sprint retrospective.
Product Requirement Document
One more product team deliverables, it is arguably important, some may say it is needed but some may not. However, this document acts similar to ‘written agreement’ and ‘contract’ on the product specifications and business flows.
Release Preparation Document
This kind of document I think it is necessary although sometimes not too important, but it is kind of professionally made (thanks to all product & QA team) and give the team awareness of how important a production release is.
Quality Engineering 🌱
Quality has always been a crucial part in every system development, thus it become our main focus of improvements.
Quality Process
- UAT (User Acceptance Test)
Our team tried to emulate the behavior of end-users, usually we did this at the end of sprint to give “finishing blow” before actual release. - Developer Testing
Our developers also need to practice and to realize the importance of testing to improve quality, so they did:
Mock API & API contract (mainly for backend team), Implement static test, unit test, memory leak test, mock test and further e2e test together with QA.
- Enhanced QA Testing
QA team as the frontline of quality, of course they need to be enhanced in skills, tools and mindsets.
E2E /End-to-End Testing
Our team used Cypress (web e2e) and Katalon (mobile e2e) as end-to-end testing tools to do regression test and automate user behavior. rizky septika don’t forget to call:
npm run cy:open to open this 👇
Load Test
To ensure our system quality in terms of performance and stability, our QA team needs to learn how to measure it. Currently, we implemented Apache JMeter and in near future hopefully Postman scripting test.
Quality Behavior
Our team (both QA & developers) are planning to implement TDD (Test Driven Development) and even further to BDD (Behavior Driven Development), again this is not just change of behaviors but also changing mindset, culture and understanding ‘the why’ behind each methodology.
Bugs/Issues Management
These are the causes that makes us ‘care’ about quality, bugs, issues, defects are everywhere. So, to catch them all, we have something in our arsenal.
- Test Case, Issues Reporting, Category and Exit Criteria
As the first layer of issue-catcher, our reporting format needs to be in some kind of ‘standard’, so this is what we did:
We tried to separate the platform (website or app), to clarify the environment (version, browser type, etc.), to define steps to reproduce, and also to give actual vs expected results.
Bugs/issues category are highest-major → low-minor, it will also reflects on the Exit Criteria (a level when the features/development considered to be done or production-ready)
Code Quality
As for the code quality standard, we use SonarQube for our code quality gate and measurement. Today, (the day this article is written) we are still using quality profile namely Tokdis way v1.0, still a long way to go…
Infrastructure 🛳
By improving this part, we hoped to increase the reliability, efficiency and to accelerate more on our development process. Infrastructure should be included not only in Build → Test → Release, but also Monitor → Plan flow (see previous diagram on Software Development Process 👆)
- CI/CD
I personally think this is the most crucial part of a modern infrastructure, to be able to support developers and other teams through continuous deployment and integration process automation. So far, we tried and used Gitlab CI + Jenkins / App Center to implement it.
- Slack / Telegram
For the team daily communication, we mainly used Slack and Telegram
- Performance Optimization
I personally believe this list will be very long (maybe unlimited) list, but some things we already did are:
* Optimize resources: package manager, search engine, chat engine, ssl wildcard
* Server improvements: auto scaling, load balancer, fault tolerance
* Security improvements: ip filtering, domain filtering, bastion, private VPN.
* Platform independent: docker-ization, container registry, using makefile
* Distributed Sessions
* Distributed Caching
* Log aggregation & Batching: Kafka, Redis, etc....
- Detail Monitoring
It is about having feedback on how our system perform and whether it could be more scalable, efficient and secure. Our team utilized some of the popular tools, e.g. Grafana/Prometheus, Sentry (we used on-premise server), Kibana, also some logging and service request tracing using Elastics & MongoDB.
Our Tech Stack
- AWS, Digital Ocean, Alibaba Cloud, Docker, EC2, ECS, ECR, Load Balancer, Auto Scale, Nginx/Tengine, Alibaba OSS
- Frontend: React JS, Kotlin, React Native, Code Igniter, Vue JS
- Backend: Laravel, Node JS, Java, Golang
- SonarQube, Jenkins, Grafana, Kibana, Elastic Search
- DB: MySQL, MongoDB, Kafka
- Google Analytics, Facebook Pixel
- JIRA, Trello (for some cases)
We also did some ‘changes’ here for example moving from DO to AWS & Alibaba Cloud. ✌️
Progression 👨👩👧👦
Last but definitely not least, Progression is about how we care of our team members more as human (or as a family member, ideally, in my opinion) being rather than just a simple ‘resources’. We are still (and keep on) learning how to apply this concept in our team.
Sharing Session and Tech Talk
I personally believe that knowledge is eternal, it is something that naturally comes not from ourselves (even though we made the effort to ‘collect’ it), and it should be spread in order to make it back to the source of knowledge and make us get the little touch of it -make the knowledge ‘stays’ inside us-
1-on-1
This is not just a regular meeting between leads and their team members, I personally believe each of us needs to have some spaces and personal goals in order to grow both professionally and personally.
Progression Framework -near future-
Sometimes during the days, we feel bored of what we’re doing, like working on the same codebase, same products, etc. Fret not, progression framework is here to save the day!
Stats
For those who likes to read numbers and statistics, hereby I present to you my team statistics during our working period together:
- 303 working days
- 2,708 Merge/Pull Requests (MR/PR) -not included many direct commits without MRs/PRs- 😁
- > 300 bugs/issues/hotfixes
- average 10.83GB Data transfer monthly (source: cloudflare)
- average 255 Firewall issues monthly (source: cloudflare) 😅
- 5x–6x hacked -not something to be proud of- ✌️
- > 1,000 JIRA tasks (not all done yet) 😅
- +/- 28 Services (not really microservices yet, let’s call some of them macro-services 😀)
- > 30 Repositories (maybe more, because this is Gitlab only)
- ≥ 15 teams of engineers (some have resigned, but all in all including product & QA they are part of this engineering team -in my opinion-)
- ≥ 30 overall team members (including operation supports, marketing, etc.)
Outro.
Lastly, eventhough we are sometimes fall into this kind of situation, Thank you for all the time given for collaborating, interacting and sometimes blaming ✌️ for everyone inside and outside Toko Distributor
Keep contact, silaturahmi/networking, keep learning, and improving and see you again
Disclaimer: this writing is not (and never) intended to do any offensive meaning to any parties, it is created for appreciating what the team did and to keep it improved (make it a culture) and also a self-note to myself as personal reminder. 🙏
Referensi
- Toko Distributor team’s accumulation of personal experiences✌️
Contact me
Linkedin: Djiwandou Putro
github.com/djiwandou
djiwandou (+62 822 3091 7591) | djiwandou@gmail.com
