We reached out to over 50 startups to ask them how they manage their code to hopefully pass on some useful tips you can use when managing your codebase. Heaps of great responses, so grab a coffee, sit back, and let’s geek out.
A big thank you to the Raygun team for sponsoring this group interview. If you want to build better software and keep your users happy, Raygun is an amazing error tracking system for software developers. Get a complete overview of bugs and crashes that are affecting your users and fix them before they cause you bigger problems. Keep your software healthy and your users happy with Raygun. Get started for FREE today.
We use git, with a feature branch workflow strategy to manage our code base and push frequently to production (also through a git-based process). This has worked really well for us, but as we added engineers and our development pace increased, the git commit history started to look a bit like spaghetti.
There are best practices to any process, and you learn them through experience. For example, the simple practice of squashing checkpoint commits and rebasing the feature latest changes to the master branch prior to making pull requests has significantly increased the manageability of our code base.
Sandi Lin, skilljar
As a startup with a strong focus on technology, CommercialTribe knows how important it is to keep code clean and managed continually.
Our team manages a fully distributed, video-based social learning platform, which means that clearly defined tools, a robust internal QA and tracking system, and strong global server capacity are actually vital to our growth.
To manage our code, we use a number of tools, but in reality, the organization is driven through defined goals, roles, and tasks. Developers have a clear sense of what they need to achieve, how they fit into the greater framework and efforts of their peers, and the best practices and methodology to get there.
You can have all of the tools and applications in the world, but if you can’t have the whole team use and embrace them, you will run into problems.
CommercialTribe operates with a variety of industry-standard tools to make code management and workflows as simple as possible. Most important is versioning, keeping all efforts up to date, so that the entire version seamlessly melds all parts and features.
We focus on JIRA, git, and gulp.js to drive our day-to-day code operations. JIRA helps us to maintain a consistent and reliable issue tracking and QA process, while git is the versioning control utility of choice.
Gulp is our task runner, helping to reduce developer time spent on the build process and increase productivity. As with most of our peers, we also drive our server capabilities through Amazon.
What do you wish you had known before that you know now?
Start early! In the first few months and weeks of starting a new development project, it is easy to let the excitement get the best of you. If you take the time in the beginning to really get a sense of what tools and practices you will need to keep code and any process aligned and defined, it will pay great dividends when growth really happens.
Overall, align your sales and marketing, train your sales team to amplify tribal knowledge, make sure your developers and projects are constantly systematic, and embrace growth with a clear vision and strong sense of order! ”
Paul Ironside, CommercialTribe
We are developing our startup using Ruby On Rails. I believe that Rails still has a lot to offer startups in terms of flexibility and productivity. We’ve been through numerous iterations in terms of servers and utilities to run the code.
We first started by deploying our app on the JVM using Torquebox and JRuby but found it lacked a lot in terms of websocket communication, which we use extensively to deliver new leads and calls to our chrome extension.
After than we moved back to MRI and the rainbows web server, using it’s eventmachine support to host faye inside our rack stack. After making the jump to Rails 4.1, we were able to switch to passenger which has improved our performance and server utilization.
As far as hosting, we have been running everything on DigitalOcean droplets and using Google’s cloud storage to host customer assets.
In terms of managing the codebase however, we’re mostly sublime users, and use the git command line to manage version histories. We started using BitBucket from Atlassian but found the UI and UX to be a bit clunky and moved the codebase to Gitlab’s cloud hosting.
Outside of hosting, RSpec is an invaluable tool for managing your code base. We recently did a large refactor of our code base, moving all the business logic out of our models and into service objects.
Having a solid test suite really sped up the process and gave us the confidence to make such a large refactor happen quickly.
We use MagnumCI as our constant integration system. If you are unfamiliar with a CI system, it basically works like this. We have hook on gitlab that pings MagnumCI every time we push new code to our master branch.
MagnumCI then checks out the code, and runs a build script that we give it. This usually means running RSpec and ensuring the build passes, but could be much more complicated in other projects. Having a good CI platform is almost as important as having a test suite.
Now no matter what, before a new build gets deployed to production, we make sure that we have the Green light from Magnum.
Another important thing we’ve found that helps with a code base in the wild is a solid Exception/Error tracking system. In the past we’ve i’ve used honeybadger.io and airbrake, but with being a bootstrapped startup we decided to go barebones, and deployed Errbit to a heroku instance.
It actually has a very nice interface for seeing backtrace, setting reminders and can be configured to hook into a number of services. We run a lot of our auxiliary services like this on free Heroku dynos to keep costs down.
Finally a good team chat server is super useful. Some great options are Campfire, Slack, Hip-Chat, or what we use now IRC. Again we take advantage of free heroku dynos and a custom buildpack we created to host an IRC server on heroku.
All our services, gitlab, magnumci and errbit will report errors to our IRC channel to make everyone aware of issues that come up, new code deployments, or CI build status in real time. Its really a great way to keep everyone in the loop without spamming them with email.
Justin McNally, LeadpopHQ
CodeSpark is building an iPad game to teach kids about computer science. We are a small and often distributed team working in Unity3D. We have an SVN repository for all code and assets, with an organized directory structure separating audio, scripts, textures, etc.
Our repository is hosted on Assembla, with additional local backups. I use Cornerstone as a visual SVN client on MacOSX and TortoiseSVN on Windows. We manage our coding tasks on Trello using priority columns separated into two-week sprints.
We avoid branching, preferring instead to use runtime configuration files or compile time flags to turn features on and off. This method also allows for easier A/B testing. We do not have an automated build setup yet, but plan to as the team grows. I’ve used Jenkins and TeamCity successfully on previous projects.
I’m a believer in code reviews and have practiced it religiously on larger teams with live products. Since our current team is small, experienced, and moving fast pre-launch, we generally only review the trickier sections of code and most bug fixes.
We have a standard coding style for indentation, where to put braces, etc. Similar to the famous broken windows theory, I find that clean, professional looking code tends to make everybody more responsible coders.
Joe Shochet, codeSpark
Our codebase is managed via github. We use pull requests for all changes, and use those PRs as our mechanism for code reviews. On large features, we will use sub-branches into a feature branch so that we can incrementally review more digestible-sized pieces.
Overall we’ve been very happy with this approach.
Seth Pollack, Rival IQ
We’re using git as version management tool in addiction to bitbucket.org to store our repositories.
We’re trying to follow an agile management approach and we find in Trello a simple and lean tool to track our activities, in addiction with Redmine, used mainly for defining milestones and issue tracking.
Our startup works on a mobile product using mostyle Ruby and ObjectiveC languages.
Other useful tools we use everyday are:
- New Relic
- Digital Ocean
- AWS (S3 + CloudFront and EC2)
- Testflight
- Flurry
We started using new relic recently and it helped us a lot for tracking performance issues, slow queries, etc.
It think we would have saved a lot of times finding issues and bottleneck with such a tool if we have started using it since the beginning
Davide Cenzi, Needle
How do you manage your code base?
We manage our code base using Git (a distributed version control system) that is served by Atlassian BitBucket on the cloud. Every new commit to the VCS triggers Continuous Integration build in order to ensure that code can be integrated and the new commit does not break existing functionalities.
What systems or tools do you use?
Git, Jenkins, SourceTree, BitBucket
What do you wish you had known before that you know now?
We’ve been adopting GitFlow in order to bring some workflow standards to our Configuration Management process. Previously, Configuration Management and releases were not managed properly and caused some problems especially during the period when we needed to do quick releases to capture business opportunities.
Henry Suryawirawan, Einsights
We are big fans of Node.js at Lever. One of the greatest things about Node is its simple but very powerful dependency management and npm.
At first, we checked our node_modules into Git, but this became a maintenance nightmare as widely used dependencies had to be manually reinstalled and updated across multiple services.
Since then, we’ve switched to keeping private modules in a private npm repository. We also have many open source projects that we maintain, including http://derbyjs.com/. For these, we publish to and install from public npm.
When we do a build, we use Docker to make sure that the image is consistent across different server instances, and we keep a log of all of the versions that npm installed at build time.
This gives us the stability of knowing what code we are deploying, safer rollbacks, ability to see the diff when modules have updated, no extra cruft being checked in to Git, and a much easier path to upgrade widely used modules across many production services.
For more detail, read our full blog post.
Nate Smith, Lever
We manage our code base through github pull requests, travis-ci, and custom rolled linters.
Linters are a series of bash scripts which are executed in a Travis step. They do mostly simple things like grep for `.only(` methods calls in javascript tests (which is a way of excluding the run to run only a single test), or debuggers or similar which are often easy to check in.
From a product perspective, we use sprint.ly for managing tickets.
Various other tools we use:
- coveralls
- travis
- github
- sprintly
- recordit (screencast to gif software)
- google hangouts
- google docs
Happy to answer more in depth, but struggling for a bit of direction on what you want. Please feel free to email me at the listed address.”
Justin Abrahms, Sprintly
We use GitHub for source control which we love. We break up our code assignments by feature and frontend/backend. We develop new features on new branches and push them to GitHub so another developer can grab the code and add the frontend/backend or test the code.
Our full stack is Ruby on Rails, PostgreSQL, coffee script, haml, SCSS, Redis, Heroku.
We follow agile development methods and try to push out several deploys per week, gather customer feedback and iterate quickly. We use Trello to prioritize, assign and keep track of feature development and bugs.
Karl Gusner, Good Audience
When we first started out, we didn’t have a single software subscription – everything was open source and hosted on our own server. So we used Gitlab instead of Github, Jenkins CI instead of Circle, tried both Kunagi and YouTrack instead of Pivotal Tracker, etc.
If you’re bootstrapping, this can make a big difference. Do your due diligence, though, before choosing a solution and decide if it’s worth the extra time, maintenance, and risks you commonly face with free tools.
We’re still using some of the free tools, but others we have migrated away from, mostly for the benefits of cloud/hosted solutions and less hesitance to pay for convenience.
Andrew Schorr, Grata
JIRA
Mercurial
JIRA Agile
Beyond Compare
Alan Chaney, Bitvore
We use :
Bitbucket as a Git repository for our code.
Jenkins for Continuous Integration
Cucumber for automated testing
Calabash Android/Xamarin for testing with device virtualization
JIRA as well as Trello for Agile development process management
For development :
Maven and Eclipse (Android/Java)
Xcode/TestFlight (Objective-C/iOS)
Canopy/Eclipse for Python
Eclipse for PHP
1SDK Inc, 1SDK Inc
We use a Ruby framework.
Our infrastructure is on AWS
We use Pivotal Tracker, github and codeship for continuous integration
Elie Toubiana, CardFlight
“How do you manage your code?
Our day-to-day development process consists of planning, coding, quality assurance and release. Unless it is a critical fix, we usually plan weekly development sprints to implement a feature / functionality.
During the planning session the tasks are divided into some logical development work pieces, which could be evaluated in time effort of 1, 1/2 or 1/4 work days. After we have this on our board, each of the development team member takes an individual task and proceeds with the coding work.
After the work is done, the code changes are firstly tested out by the developer locally on his workstation, afterwards pushed to the code repository. Before merging the code to the master code branch the code is firstly reviewed by at least one other developer and either he / she leaves some comments for clarification or with a modification suggestion, or is approved and so merged with the master code.
After this is completed, the code is pulled to the servers of the development environment, where all the team members can test out the added code piece, whether it is a fix, a new feature or functionality.
Lastly, when all the additions form the result of the planned sprint the code is deployed in the pre-production environment, where final test are done with real database copies and on acceptance it goes live by deploying the modified code on the production systems.
What systems/processes/tools do you use?
For the development coordination we took the Scrum practice to plan the sprints and achieve the continues development and improvement for our product development. Going more technical our product is mainly built on PHP, so everything that we find efficient and what increases productivity always are in our spotlight for use – frameworks, classes, good source code examples found publicly.
The developers on their workstation are using the tools of their own choice – not the tools, but the result is what matters most to us. And after we have what to show to the world, we publish our product on the servers, which are hosted in the Microsoft Azure cloud at the moment.”
Sarunas Legeckas, PlaceILive
As far as overall project management goes, Heyo typically tries to keep one repository of core library code per language we use and one repository per application. Where an application can use many languages and produce many builds.
Our application repositories are typically structured to house many services which act as a root sub-project in a repository. Each service is written in a single language and uses its languages tools for managing its dependencies, test runners, builds, deploys, and other bells and whistles typically needed to manage the life-cycle of a project.
If a service ever has some code that needs to be shared with other services, those modules are typically rolled into the language’s core library so that all services can have access to the functionality.
Although we are not quite there yet, we plan to start versioning the core libraries so that we can safely make updates and not worry about having to update ever single dependent service.
Heyo uses a pretty standard workflow with git. As far as tools are concerned, we mostly use git on the command line in conjuncture with github’s pull requests for code reviews and triggering our automated tests which are ran via Travis CI.
We manage projects and track defects using Fogbugz. We start a “”project”” for each repository, a project for tracking customer service requests, and a project for tracking defects sourced from in house quality assurance/control initiatives.
With global milestones we can coordinate sprints and releases across all projects. To provide some rough real-timeish updates to the rest of our team we use the Kanban plugin.
For planning we typically take a look at the past few months worth of completed work and roughly determine the team’s weekly (our sprint length) capacity. Stories are sourced from each fogugz project’s product backlog.
Acceptance criteria and story priority are both the responsibility of the product owner of a project; a product owner can manage many projects. Once the product backlog is locked for a sprint, senior developers look over most of the top stories and write in some rough implementation notes.
The development team then does some estimation using our weighted story points. Once acceptance criteria, priority, development notes, and estimations are in a sprint is compiled for each project.
Coordination between teams to keep the entire platform stable is key when building sprints. These processes and tools help to keep Heyo focused and aligned with our goals as company.”
Eric Bittleman, heyo
“We use git for version control across all of our code bases (we currently maintain 4 websites, an Android and iOS app for our therapists and an iOS consumer app). All of these are hosted on Bitbucket – why did we not use GitHub? Because Bitbucket give you an equal feature set – for free (always important for a startup!)
We run a feature/bug branching strategy – all of our issues are reported into our JIRA on-demand instance (we used to work in a large-scale corporate environment and decided JIRA and Confluence were simply too valuable to miss), linked to our Bitbucket instance for easy branch creation and auto-referencing back from commits to the related issues.
We have about 30-40% automated test coverage across our web & server-side code bases (all end-to-end NodeJS), sitting on top of a mocha/chai framework and a small amount of selenium-webdriver automation.
Once we are happy with a feature/bug branch, we have codeship.io setup to automatically run our full test suite upon pushing to any branch. This replicates a full environment, including multiple neo4j, redis and elasticsearch instances.
We then perform smoke and feature testing within our staging environment, and when happy this gets pushed to production. Our use of Heroku for most of our web-processes makes one-line deploys incredibly quick and easy.
For our mobile apps, we have a number of test devices to hand – once we’re happy with how any updates perform in the simulator, we push out builds linked to our staging environment to our test devices to perform feature-testing upon, and when happy we push out a production build to our live devices. We use testflightapp.com for iOS distribution (sitting on an Enterprise iOS license) and testfairy.com for Android distribution.”
Giles Williams, Urban Massage
We follow the agile development process, with scrum every morning and short short one week sprints. Each sprint ends with a releas to a staging environment every Friday night. The sanity tests are run during the weekend on a smaller version of our network, and if all tests pass, we release the previous week’s build to production on Monday evening.
We plan our sprints every Monday, based on a roadmap that spans the next 3 months or so. We try to make every sprint or every few sprints have a major theme, so our team have a sense of accomplishment and know they are working towards concrete goals.
We use Team City as our build server and YouTrack as a scrum board.
We use Github for version control and Github’s pull request feature for code reviews. We do code reviews religiously to enforce quality and consistency across of all our code.
Tina Denuit-Wojcik, Enplug Digital Signage
“Processes:
Agile Development
Tools:
Jira
Vagrant
Puppet
LAMP Stack
Redis
Memcache
Elasticsearch
RabbitMQ”
Josh Holat, StageBloc
Version Control
For version control, we use Git/Github. Pretty much the norm these days.
Agile Management
We use a couple of tools here: Pivotal Tracker to organize things and prioritize tasks, and Git Flow as our workflow tool for all features and releases.
We are looking into moving towards Continuous Integration though, so Git Flow may have to go away, or we’ll use some modified version of it.
Testing
Rspec and Cucmber for Rails. PHPunit for our PHP stuff.
Deploying
Capistrano and Cloud 66. Capistrano is used for some of our smaller applications, while Cloud 66 is used to manage our major applications and manage our servers.
Ian Fosbery, NMRKT
We manage our code using git, github, and conventions. The most important convention is that master is always deployable to production and deploys are cheap (one command, do them early, do them often).
Most development work happens in feature branches and we strive to make code reviews very small (usually only one or a few commits). This means we don’t use pull requests. By the time we are merging a big feature branch into master several code reviews have happened and all tests are passing.
We have fairly comprehensive test suite. We call all of our tests unit tests, but they are all integration tests in one way or another — we seldom go out of our way to test some piece of code in full isolation.
We use github issues to track bugs. We triage these once a week and every developer on the team has at least one scheduled session devoted to working on the bugs each week.
Our github account is also integrated with our iDoneThis account; a summary of how many commits to each branch is automatically included as a “”done”” or accomplishment and shared with the rest of the team. This kind of asynchronous communication is very important to us as a distributed team.
We keep track of technical debt by having a list of “”cleanups”” to do at some point. The idea is to think of the cleanups like we do of bugs: have them triaged and schedule a time for every developer to work on them, but we haven’t found the time to put that process in place, yet.
Walter Chen, iDoneThis
There are a number of tools that enable us to build the Kloudless API, the storage layer for the cloud.
When it comes to managing code, we use Git for version control and Gitlab, the open source clone of GitHub, as the central way to manage code, bugs, merge requests and code reviews.
Another member of the team reviews each merge request made on Gitlab. This process helps ensure a high standard of code quality and increases the team’s awareness of different sections of our codebase.
In addition, we use GitHub to host and share open-sourced Kloudless SDKs for Java, Android, iOS, NodeJS, and Python. Also available on GitHub are open sourced UI tools such as the File Explorer and Authenticator JS libraries. These tools enable developers to get started on the Kloudless platform within minutes.
For deployment purposes, we use Fabric, a python-like orchestration library to script actions on remote servers. Prior to deployment, we do some automated testing and combine it with manual testing. If we need to rollback, we simply revert to the previous version before re-deploying.
Our server and system configurations are managed via Puppet. Webhooks on our Gitlab server automatically deploy code to other components of our infrastructure and lets Puppet know that a deployment has been initiated.
Vinod Chandru, Kloudless
We use NetBeans as IDE and the code base is maintained on a GITHUB repository. All the developers add their code to this centralized repository which is reviewed & approved by the lead and pushed to test environment. After UAT, the code is deployed in the production environment.
Sarvesh Agrawal, Internshala
We use GitHub for everything that has to do with code. I’m used to Phabricator for code reviews from my time at Facebook, and I imagine we will start using that once we grow our technical team beyond us founders. GitHub is good enough for that for now though.
In order to be able to move as fast as we want, we make sure to automate as much as we can of the pipeline, from checking in code to deployment.
We use a combination of Jenkins and XCode Server for continuos integration. All our tests get run on each commit, so we instantly know if one of us accidentally broke something.
We have built an amazing tool for cloud provisioning and deployment. It lets us do everything we need with one click instead of having to spend lots of time setting up keys etc. We hope to make this tool available to the public at some point.
Torbjørn Morland, Memkite
Managing code is hard business; fortunately, the tools already available allow us to spend more time on the funny part of the trade instead of dealing with conflicts, unexpected bugs or pure noise.
At Wazza, our stack is happily composed of a lot of different technologies ranging from the normal stuff to more exotic languages, frameworks and architectures. Our codebase is huge but fortunately, git comes to the rescue and Github is used to host everything.
Every issue, feature or improvement is tracked on Trello which automatically notifies the team in Slack. After being carefully tested, all the code is committed to the upstream branches using Pull Requests. A lot of this work is also validated using Continuous Integration techniques with Jenkins.
Duarte Barbosa, Wazza
Our codebase is in PHP and Javascript (For frontend and some services in nodejs). As for code/directory structure:
- PHP: We follow Laravel’s folder structure.
- Javascript/Frontend: It’s RequireJS, so everything is a module, and there’s a page specific “”controller””.
- Javascript/Node: CommonJS, the services are isolated and have their own components.
We use GIT + Gitlab to store source code. We do merge requests and code reviews in Gitlab. We also use it to store code snippets.
We follow this philosophy of GIT branching (http://nvie.com/posts/a-successful-git-branching-model/), but the develop branch is less used since we prefer small incremental changes because it makes it easier for code reviews.
We keep everything related to the website in 1 repo. It makes it easier for deploying, especially with the services.
Our tests are still small so each developers runs the test locally/on staging before the merge requests with master. We’ll probably integrate some sort of CI system one day.
Ansible controls our deploy, provision and configuration. The deploy playbook first builds the release, then SSH into all our servers to fetch it and replace. It also detects changes in services code (via a simple md5 difference), and reloads/restart if needed.
Logs are centralized using Kibana + Elasticsearch.
Makara Sok, Player.me
TransferGo are typical of many forward-thinking technology companies, we use Git as our core source control system and we use feature/topic branches to develop new features, as well as change requests and bug fixes.
We also apply key test-driven principles to our software development cycle using tools and frameworks such as PHPSpec.
We also have strict code review processes in place. After ensuring that each unit of work is discussed upfront and understood by all involved, we encourage developers to first stub and flesh out their idea’s surrounding implementation ready for several team members to comment and review before any serious implementation is done.
At the end of their work we also use the tried and tested pull request workflow to catch any post-implementation issues.
As we have a small team, we need to free them from maintaining complex systems and keep them focused on delivering product. To enable this we utilise cloud based ancillary services like GitHub/Bitbucket to host our Git repositories; Scrutinizer CI to power our code hygiene, code standards, and validation of our platform through executing unit/integration tests; and, JIRA Agile & Confluence to drive and manage our communication and workflow.
All of the above is also tightly integrated into the developers IDE’s to reduce cognitive load on the standards and procedures they need to process and remember. This allows our developers to focus on the task in hand.
Jon Webb, TransferGo
We use Github for source code management. We use Jenkins for our continuous integration build and deployment processes. We use agile sprints to build out software. At the end of the sprint code is branched and pushed to production. Fairly standard agile methodology.
Franz Garsombke, Rachio
The Wedgies code base (I love saying that) is predominantly NodeJS. Here are the tools and tech we use to manage our code and assets:
GIT/Github – Centralized repository for our Decentralized Version Control. Just using GIT isn’t enough though. You really need a process/philosophy around how you manage code that is under development and code that is ready to release.
What you don’t want is to end up in a stage where you can’t push a bug fix because there is code in the same branch that isn’t ready to be released. To help with that we use…
GitFlow – GitFlow is a toolset that sits on top of GIT and implements a model of feature/hotfix/release branches that make it easy for a team to continue working and releasing without waiting on each other.
Trello – this is where we keep track of what we are working on. The most intresting thing we do here is the last column in our dev workflow is called “”Shipped Week X”” where X is the current week of the year (right now is week 40).
At the end of the week, this entire column gets moved to a new board called “”Shipped”” and a new column called Shipped Week X+1 gets added to the dev Trello board. This allows us to look over what has been shipped a week at a time for the entire year.
Wedgies – Shameless plug, but we use Wedgies.com to let our users vote on what features they are excited about seeing next and use that to influence our roadmap.
Slack – Slack ties everything together. We have a development channel for conversation and for webhook notifications from Github, Trello, New Relic, Papertrail, etc.
Jimmy Jacobson, Wedgies
Cloud hosted git via aws instance. Cloudforge/Asana for team management tasks
Siddharth Gupta, InviteReferrals
Back in the old days I remember calling out across the room to another co-worker “”Are you editing style.css””? They were dark days. Two people writing over one file in a project was a total cataclysm.
These days? It’s a whole new world. With private GitHub repositories, we have an automatic deployment mechanism with AWS. Scott Sanders, our Digital Director, wrote this elegant staging system which spins up remote staging repositories with LAMP environments in one click.
Murray Bunton, AGENCY
We love using git to manage the different features we try to push out. Along with Github Issues, we are able to track down bugs and immediately release fixes to specific branches of code.
Michael Scaria, Fortheon
</div