How do startup companies add new features to their

How do startups like say Feedly, or Buffer make changes to their code, by adding a new feature and at the same time testing it out without breaking things? Is there a framework for sandboxing, does it have to be built in house, or is it just cloning the git repo on a localhost and playing around?

回答1:

It's called a Staging-Environement and you'll find many resources online in regards to Testing and Software Quality.

Sandboxing on the other hand is a security mechanism for containing untrusted programs.

回答2:

There are many specific techniques which make it possible to add features to software and deploy it to a running site without breaking things. It's a big topic, but here are some current best practices:

Plan features to be easy to introduce: as small and independent of one another as possible, given business requirements, and thus easy to assess and change or revert if necessary.
Choose architecture that minimizes the scope and impact of each deployment. If an application consists of independent services accessed by defined APIs, a deployment can update and restart a single service, reducing the impact on the entire application.
Plan implementation of large features to be easily deployable: implement in pieces, all but the last invisible to users and deployable over multiple deployments, thus reducing the risk in any one deployment.
Since the site is running when you deploy, it's necessary that consecutive releases are compatible. For example, changing the database may mean three production changes: first change the software to run on both the old and new versions of the database, then make the database change, then remove support for the old database version from the software. You might also need to ensure that the current version of a browser app is compatible with successive releases of the server-side software.
Feature flags, aka feature toggles, remove some of the risk from deployment by leaving features hidden until an administrator activates them at runtime through a UI which is part of the application. Feature flags also allow rolling back a feature without rolling back the entire application if the feature has a bug or negatively affects the business. Wikipedia lists a few feature flag frameworks and you'll find more if you search.
Thorough automated testing and continuous integration prevent unexpected breakages. Manual regression is too slow, unreliable and expensive for any web business, and especially for a startup. Continuous integration makes sure that the tests are run every time a change is made.
Automated deployment prevents manual errors during deployment and makes it easier to deploy more often, meaning that each deployment contains less changes and therefore is lower risk. (Continuous deployment, aka continuous delivery, is simply completely automated deployment, meaning that no-one even has to press a button.)
Canary deployments allow changes to be exposed to a subset of users in production before committing to a full rollout.
Monitoring is essential to catch bugs that do get deployed to production. Monitor both low-level metrics, e.g. server and service uptime, and high-level metrics, e.g. credit card charges per minute.
Automated rollback minimizes risk and downtime when a bug does get deployed to production. At minimum one needs to be able to roll back to the previous release with no more than a button press. For bonus points, roll back completely automatically when a critical metric drops below a threshold. Blue-green deployment provides a fast way of rolling back.

Humble and Farley's Continuous Delivery covers many of these topics. I realize you didn't ask about continuous deployment, but many of the current best practices that support rapid iteration lead up to or fit well with continuous deployment, so it tends to be all the same discussion.