From managing a legacy platform to handling Node.js in production
What is SIESGSTarena?
SIESGSTarena is an online community of competitive programmers and a contest platform which hosts programming competitions. Our mission as a community and as a platform is to help programmers learn, share and improve themselves in the world of algorithms.
How the platform has grown in the past?
About 2 years ago we shifted to Node.js and MongoDB from PHP and MySQL because of the problem of scaling and infrastructure. Our aim was to make the website work in a more asynchronous form. The performance boost of Node.js was incredible and also at the same time we wanted to make it easy for us to ship changes every week. This decision turned out to be very great for us.
The real problem of understanding the Legacy Code.
We remember the day when we had seen the code base of the platform. We were really scared as at that time we weren’t having any prior experience of working on such big projects.
But the good thing was that the folder structure & documentation of the code base helped us understand the code faster and eventually the fear was also disappeared.
“So if you want to go fast, if you want to get done quickly, if you want your code to be easy to write, make it easy to read and understand.”
Running Node.js in production :’-(
At first we lacked experience on how things work in production environments on real servers and also we didn’t want any downtime for our website. We created different branches for working on different things like features for front-end developer and dev for backend developers. Because of this everyone has full independence to try out new things. Along the way the tool that is helping us a lot for managing our repositories is GitKraken. It has a great Intuitive UI/UX which inspires us to work more and a special merge conflict editor. This makes our complex task more easy and intuitive. Also the Glo Board in GitKraken makes Task Tracking super easy.
Branch Protection
We implemented the branch protection policies for our repository. This means that a developer can only push to dev or features branch, and master is only accessible through pull requests. This helped us to make our live website stable and minimise downtime by ensuring that only efficient and error free code goes into production.
Using GitHub issues to keep track of work
We maintained the GitHub issues in our private repository for our internal purposes, like increasing the efficiency of a particular function and to make the architecture more and more robust.
Also we have a public repository which only focuses on issues faced by users and also some improvements or new features they think are worth adding.
This has helped us to create a balance between the development of new things and improving the existing ones to increase user satisfaction.
Segregating issues using labels
Labels are very useful when not all the developers have the complete understanding of the problem, how much knowledge or time is required and whether it is good for a newbie or does it need an experienced developer.
We segregated the labels as ‘bug’, ‘good first issue’, ‘ enhancement’, etc. This has helped us pick up the issues faster and assign them to appropriate developers.
Magic of Continuous Integration and Continuous Deployment
The main problem in fast pace development is that no one has time to test each and everything before deploying to production after every code change. This makes the release of new versions and fixing bugs a time consuming process and which frustrates the users facing the bug and developers writing new features.
For this we chose Travis-CI. It is a hosted continuous integration service used to build and test software projects hosted on GitHub. It tests your code automatically every time when you push to any branch in a repository. You can write custom tests for simulating actual world processes. This gives us confidence that this release won’t be failing in production as Travis-CI makes a separate sandbox environment for running the code in the same way as our servers do.
Travis-CI works great with GitHub as the pull request created to master branch will only get merged if all the tests have passed. This protects us from bugs getting into production.
“In software, when something is painful, the way to reduce the pain is to do it more frequently, not less.”
As soon as the code comes into the master branch the notification is sent to Heroku using Webhooks and Heroku starts building a website with the latest code and Voila! The new Site is live in seconds. This workflow has helped us a lot in terms of developing new things, testing them and delivering them on time.
What’s Next ?
We are currently working on breaking our Monolithic architecture into Microservices architecture. Which will give us power and control over all individual services and so that we can scale and update any particular service without affecting other services.
The best thing about our platform is it is completely designed, developed and managed by a small group of students. because we believe in
Finding something that we can’t do, and figuring out how to do it. Whatever it takes.
