-
Notifications
You must be signed in to change notification settings - Fork 0
Research studio post mortem notes
PRs, code reviews, issue tracking, etc.
Probably just an update of the contributing doc?
During the development of Bloxeo, we had many practices that helped to make the process as smooth as possible. The most important part of our development cycle was to use a reliable version control system such as Git/GitHub to prevent loss of work and to be able to fix mistakes. In order to implement the features given to us during each two-week sprint, we met regularly each week to go over what had to be done that sprint. Each task would be broken down into smaller tasks and assigned to each member of the team through GitHub issues. When a member completed their assigned task, they would take another open task and continue working.
To make sure each task was completed in a consistent manner in terms of programming standards, a linter (ESLint) was used an configured to the needs of the project and follow proper JavaScript standards. Before pushing a completed task to GitHub, the linter had to be run on the code and any errors had to be fixed. To ensure the code worked as expected, unit tests were also created using a JavaScript testing framework called Mocha. In order to enforce these practices, a continuous integration and deployment platform known as CircleCI was set up to automatically reject the ability to merge any code into our 'stage' branch on Github if any branch failed the required tests. If the tests succeeded, the team participated in code reviews of each completed task to ensure code quality and catch any potential issues. Once two team members had looked over the code, the finished task could be merged into the main code base.
After each sprint, or after several important features of Bloxeo were implemented, a new release of the platform would be made. we would assign a new version number appropriately, and push to our production server on our current host server on a web platform known as Heroku. From here, the client team could test their code properly and report any bugs not found during the initial development cycle.
Couple of paragraph description accompanied by some diagrams.
Could be ASCII art, sketches, whatever, branding will make them pretty and consistent.
- Server architecture.
- Client architecture.
- Communication channels between the two.
Choosing which transport and persistence layer to use for each use case.
- Socket vs HTTP
- Mongo vs Redis
Problems with Sails:
- Waterline
- Slow queries
- Out of date Express
- Out of date Socket.io wrapper