Why no one should use FTP for team development

This entry was posted on July 29, 2014 by Brent W Peterson

FTP has been the most common way for developers to access a website but is it the best?

Wagento uses a process called "Continuous Integration" This allows for a group of develpers to colaborate on a single project. Wikipedia lists the following advantages

  • When unit tests fail or a bug emerges, developers might revert the codebase to a bug-free state, without wasting time debugging
  • Developers detect and fix integration problems continuously — avoiding last-minute chaos at release dates, (when everyone tries to check in their slightly incompatible versions).
  • Early warning of broken/incompatible code
  • Early warning of conflicting changes
  • Immediate unit testing of all changes
  • Constant availability of a "current" build for testing, demo, or release purposes
  • Immediate feedback to developers on the quality, functionality, or system-wide impact of code they are writing
  • Frequent code check-in pushes developers to create modular, less complex code
  • Metrics generated from automated testing and CI (such as metrics for code coverage, code complexity, and features complete) focus developers on developing functional, quality code, and help develop momentum in a team

In more simplistic terms it works like this:

  1. Developer works on their local Machine and they push updates to the repository.
  2. The work is checked out on the dev site for review - The Q/A team then reviews and approves for client to review. If things look for from here it goes to Staging.
  3. The code is deployed to Staging using DeployHQ where the client approves the work. Staging is the closest thing to production so we can see items in near real time.
  4. Once everything is approved on Staging then the code get deployed to live and checked again. The deployment process offers the ability to roll back if needed.

In some cases, before a site goes live we may only use one or two places for testing. But once a site is live and in production the before mentioned procedure is used. Once the site goes live we turn off FTP and do not let anyone modify code on the live site.

You may ask why? Why do we do this process?

Scenario #1 (Most common)
Third party developer installs feature on live site without putting code into repository.
Wagento deploys a different feature to live and third party code is overwritten.

Scenario #2
Third party developer installs something on live site that breaks lives site, then goes to bed.
Client calls Wagento to tell them live site doesn’t work
No one has any idea what was done and code is not in repository so code can not be tracked.

Why do we care about any of this?
The repository creates a real time audit trail of everything that has happened to your website. If there is ever a problem it can quickly be identified by the last submitted code and that code can be reverted or corrected. Once someone works outside the system the code is no longer valid. The integrity of the website is now in question.

Why do we care about the integrity of the code?
We have clients who every day are fulfilling 1000-3000 transitions and 10,000’s of products. If we don’t know what the state of the code is and how to resolve problems then we can not serve the client to the best of our abilities. In addition to integrity it can waste everyone time trying to figure out what a third party has done.

Why do we use GIT?