From managing a legacy platform to handling Node.js in production

Image for post
Image for post

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.

Image for post
Image for post
~via Silicon Valley Season 2

The real problem of understanding the Legacy Code.

Image for post
Image for post
~via GIPHY

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.

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.

Image for post
Image for post

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.

Image for post
Image for post

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

Image for post
Image for post

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

Image for post
Image for post

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.

Image for post
Image for post
~ TravisCI Dashboard

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.

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.


CodeChef SIESGST Campus Chapter

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store