We are doing a lot of work at Connected Cars and there is a lot of expectations around what we are building and we are expected to be on deadline and for that, we need to spend the least amount of time on non-essential work. So here is a short description of how a normal feature is made.
We love this program as a lot of others do, it is a super simple tool for designing and prototyping screens, nothing really beats it at the moment. Sketch comparing to Photoshop is also a lot better for developers because it has a lot of extensions that allow for quick and easy export. Also, we really like SVG and WebP for the much smaller file sizes it generates compared to the normal PNG and JPG.
Kanban with Trello is really easy and upload of images and moving cards is a breeze, so we use Trello both for our weekly tasks and for sprint planning. Each Thursday we meet as a team and discuss which issues we should work on and what is most important to accomplish the following week. This is a really awesome process and it allows everybody to have a say in what they think is most important and we can change focus when something unseen shows up.
We store everything code related on Github. There is a lot of alternatives for version control but nothing beats Github in speed and stability and the UI is simple and easy to go to. We also use Github Issues for managing bugs and features that do not have a user story directly attached to.
After a feature has been created as a Github Issue, the issue will be assigned to a person and then we estimate the task directly with a new comment. Estimates are generally a difficult thing to do and you often get it wrong, but the estimate is a way for the developer to indicate how long he/she thinks it will take just so that if the tasks takes longer than expected we can talk about it how to solve it together, instead of trying to battle to solve it yourself if it is an impossible task.
We put a lot of weight on code review, early feedback is especially important so that you know that you are on the correct path and don’t have to change a lot later because it might had to be made in a different way. Code review is also a good way to both the reviewer and creator to talk about what is the best way to solve certain problems, sometimes much easier than to discuss it in theory.
We use Docker both locally and for deployment. We use it locally to spin up our webserver, loadbalancer, database, document store and in-memory database, somethings docker makes really easy with only a single command, “docker-compose up”. On our continuous integration service, we push the finished docker image that we build to Google Cloud Docker Registry. This ensures that it is the same docker image that we tested that is going into production.
When a pull request is submitted then CircleCI will begin to test the code. What it does it basically spins up a whole copy of the system, the same we are running locally, that takes around 7 minutes from scratch. This ensures that we always know it works and that nothing broke without us knowing. With that it runs from scratch every time also means that you could take a completely new laptop and begin working in 10 minutes. We really try to always keep it below 15 minutes because that just makes it so much quicker to get started with for a new person on the project.
Once everything has been built and CircleCI says it is green, then we have a Slack bot called Bender, who has reassembles to Futurama, that do all the hard work of accepting the code into our master branch and also for deploying the changes to production. The idea is that Bender will be a central place for everything related to the platform, you don’t have to go onto any new website to deploy and it is then pretty transparent who is in the middle of a deploy if something goes wrong.
There is a lot of competition in the cloud hosting market, but Google has no doubt a lot of forces moving their platform forward. They were the first to launch a hosted database with auto-expanding harddisk space and their hosted Kubernetes is no doubt in first class as Kubernetes has become the cloud standard for managing containers.
You build / You deploy / You test / You fix
As a last note to how we work, this sentence is a general mantra. There is no strict way or workflow to follow when working at Connected Cars, that means there is both a lot of freedom but that also gives a lot of responsibility. You can make some new feature and deploy it yourself in the matters of minutes which is extremely powerful, from idea to deployed in less than 30 minutes. It feels good to know that what you work on can be seen by users the same day you make the feature. That however also means that if something goes wrong with that new changes you made, you are also responsible for fixing it.
We are growing each month and are constantly aware and thinking about how we can continue to improve, you can not innovate if you are not moving.