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.
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! ”
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.
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.
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.
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)
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
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.
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.
We manage our code base through github pull requests, travis-ci, and custom rolled linters.
From a product perspective, we use sprint.ly for managing tickets.
Various other tools we use:
- 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.”
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.
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.
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)
Canopy/Eclipse for Python
Eclipse for PHP
“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.”
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.”
“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.”
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.
For version control, we use Git/Github. Pretty much the norm these days.
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.
Rspec and Cucmber for Rails. PHPunit for our PHP stuff.
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.
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.
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.
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.
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.
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.
- PHP: We follow Laravel’s folder structure.
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.
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.
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.
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.
We’re so fortunate that only one person touches our code (the same guy who designs it, too). But, we do pay for GitHub, which was helpful when we were working on Pushpin for iPhone (http://pushp.in).
Zach (co-founder) would write the code, Jeff (iOS expert) would review it and send it back, Zach would clarify, and then Jeff would fix or merge it. This process was a bit painful as both of our engineers were trained in wildly different environments (DIY Hacker vs. Stanford CS Master degree), but it led to a much better customer experience. We’ve had only a handful of crashes nearly a year after launch and 20% monthly actives.
GoogleDocs. We have three sheets, “Do Now”, “Do Tomorrow”, “Do at Some Point”. When something is done, we toss it into a pile of completed stuff and keep moving. We usually end up adding so much stuff to “Do Now” that every few weeks we shift everything back. “Do Now” becomes “Do Tomorrow”, “Do Tomorrow” becomes “Do at Some Point” and “Do at Some Point”…. well you can guess what happens to that guy.
Spacious primarily uses Github to manage its code repository. We have multiple developers working on our codebase at any one point so managing code conflicts is very important for us.
We have a clearly defined process which involves a developer taking a current copy of the codebase and creating a “”branch””. When the developer has finished making his/her changes, they initiate a “”pull request”” which puts the code changes into a holding area for review by another developer in the team.
Once the “”code review”” has been completed, we “”merge”” the code back into the master codebase by essentially inserting the new code into the master codebase and resolving code conflicts manually.
This final step is largely automated but human involvement is required when a code change conflicts with another change made to that same section of the code after the date of the original code copy (branch creation date).
“CleanClub.co is a NodeJS and AngularJS app.
We use grunt to automate a lot of our processes, such as sass compiling, jslinting, template preprocessing and minification.
We use npm and bower to manage various packages.
Our server code (nodeJS API) and client code (angular app), while living in the same github repository are kept in separate directories with their own package.json files, gruntfile.js, and readme.md. It’s really good to have a clear separation of code, even if it means having to run processes in 2 or more terminal windows.
We have 3 sites: Preview, Staging and Production
Preview is used to demo specific branches to non-devs.
All 3 sites run Monit to keep NodeJS running.
Our deployment process is as follows:
1. We commit/merge to master
2. Our Staging server runs Dokku. So it automatically pulls from master branch.
3. Staging runs all the necessary processes (e.g. grunt tasks)
4. We test to see if staging is ok
5. If all is good, we rsync the files from Staging to Production”
At Bornevia, we manage our codebase within a bitbucket repository shared with the whole engineering team. We setup our in-house internal backend service-oriented system with REST-API structure to help organize separate modules used uniformly throughout multi-platform applications that we have or will plan to develop.
This way it makes our software development process language/framework-proof (since everything translates to a particular data format) therefore easier to scale and organize our team in the future.
At Harmonia, we develop using git and github as our source control, and we rely very heavily on rebasing (particularly interactive rebasing) to keep each commit clean and easy to understand.
We do use feature branches when working on larger changes, because this makes it easier to switch back to the deployed branch for bug fixing, and it also makes it easier to prototype ideas and then throw them away when we are done.
For deploying code, we use a great library we worked on with Go Free Range called “”recap””, which is a set of capistrano recipes for deploying code that uses various features of git to make deploys super-fast.
For example, it avoids running migration tasks if the migration code hasn’t been touched, and avoids rebuilding assets if those files haven’t changed since the last deploy.
Sublime Text. We do our best to comment out all code, keeping linebreaks where they should be to make the code legibleb for another coder.
Our systems are purchased custom from Chillblast PC’s. We are all in 8gb ram running with powerful quad core processors.
We use programs for video editing (Vegas). PuTTy, Filezilla for filetransfer, various Virtual Private Servers with the guys at Digital Ocean to provide our clients with super fast hosting!
Indesign for document creation, Photoshop/Illustrator for graphic works, amonst a few other programs this is usually what we spend most of our day with!”
Use Git, branch accordingly. Write tests on complex logic, and apply continuous integration.
Test manually before each release, write release notes. Test other stuff as well, such as performance (using Yslow and NewRelic), and security (against XSS and SQL injection), and cross browser compatibility.
If high load is expected, use a stress testing tool, and make sure both your app and infrastructure can scale. Multiple scenario of seed data is helpful.
If a code best practice tool available for your chosen framework, use it. Some investors now do technical due diligence and they wont want to see spaghetti code
As being leader Python Django job recruitment service, Core principle of Djangojobs.Net is “”Keep it simple””
OS – Hosting:
We run Ubuntu Linux 12.04 (LTS) on Amazon EC2.
We Store the original versions of our static objects in one Amazon Simple Storage Service (Amazon S3) bucket.We use Amazon CloudFront to distribute them to several locations to serve to visitors from all around the world.
We run Python Django 1.6 Web Application Framework.
We use Gunicorn as our WSGI server on NGNIX.
We store data in our SQLite database which run in Amazon EBS.
We use pngquant is a command-line utility and a library for lossy compression of PNG images to show our company logo images faster on our main page.
We use PingoScope to monitor availablity of our servers externally.
For Python error reporting we use Email reports of Django Error Reporting.
We use separate VPS server to test our new feature developments.
We use GIT source code version control system.
We’re primarily doing iOS development publicly (with Android and backend projects in the works).
Systems-wise, practically everything we do it built on Mac. OS X Server with Jenkins (hosted in-house) for CI, GitHub for code and issues, Trello/gdocs for keeping track of progress. Slack for keeping in touch. Crowdin for dealing with translations.
Like everyone else in the startup-universe it seems, we’re Scrum-ish. Product owner, dev team, weekly cycles, etc. Sometimes more formal than others.
Code doesn’t get merged in until someone performs a code review.
We automate as much as possible though, since humans are terrible at repeating processes. The code-base has been through quite a few hands, so the test coverage isn’t/wasn’t where we’d like it to be, but that’s improving as we revisit/refactor. But for things like App Store screenshots, especially as we grow into new localisations, automation saves us (literally) hours.
On iOS specifically, we make use of open source as much as possible. We’re using CocoaPods to pull in dependencies. Shenzhen helps us build/distribute (via HockeyApp – also used for crash reports).
The production website is a static S3 instance, built using Mixture.
Lime&Tonic is developed on the LAMP stack and employs Subversion for source control. Netbeans as the preferred IDE (Our CTO was one of the first team members at Netbeans prior to it being sold to Sun Microsystems in 1999).
Our development methodology is loosely Agile based, we have weekly meetings where technical tasks are discussed and reprioritised according to the rapidly changing requirements of our market place. Jira is used to track these development tasks as well as bug reports.
We have periodic code freezes where larger functional and architectural changes are worked on. In terms of handling support we have a team of first level support staff using Zendesk who pass technical requests back to the developers.
The core development team are further supported by a UX expert and server administration personnel.
Shortly after I first started Vizually, I realized if this was going to work it was important to have systems in place, so everything ran efficiently for clients. I mapped out the whole process several times over to figure out what made the most sense.
We are WordPress based, so we only use and have to manage two main themes for clients. That keeps things simplified on our end and allows us to work quickly and keep support issues to a minimum. We keep a log of code snippets, that saves time from having to figure out the same issues over and over again.
We use Wordfence Security to immediately notify us of new updates for each site, which we promptly notify clients about and begin updating the sites that we manage. The tools are extremely helpful, but having a process or system in place for everything is what keeps it all manageable and working smoothly.
Our platform is built primarily using Ruby on Rails. However, we’ve got tons of other technologies hooked in to make Jr.DevJobs more user friendly, scalable and of course run a lot faster. We’ve adapted these tools throughout time by responding to growing pains, talking with a our users, monitoring server logs and learning from other companies.
When we’ve found an area in need of improvement we investigate the competitive products to determine which solution works best for us and then schedule it on our development Kanban.
Our developers test and code it by using ‘feature branches’ on GitHub. We then have a review of the code and resulting impact to the application in our Sandbox environment. If we’re satisfied we deploy it to Production on Heroku.
Some examples of what we’re using at Jr.DevJobs include:
As we continue to grow we’re constantly evaluating ways to improve the security, stability and flexibility of the platform as well as the overall value we deliver to our users.
We’ve built a content management into our platform to keep our code up-to-date. We update themes every month and keep work on UI updates locally with MAMP Pro and push up UI tweaks periodically. Our code is stored with Bitbucket and we manage our repository with Tower.
We’re working toward systematically analyzing how our users interact with our platform using Google Analytics, CrazyEgg, MailChimp, Olark Chat and Optimizely (A/B testing). The key is to integrate all of these tools using one piece of code with Segment.io.