First time teamwork (PHP): version control and continuous integration?

Question

A colleague and I are going to be working together on a single project for the first time. This raises a few technical questions for me. Like how.

I think a version control system is a must now, if it wasn't already as a single developer.

But this also means that I can no longer simply upload to a development server via SFTP up on hitting CTRL+S. So I suppose this is where CI (continuous integration) comes in?

This also means choosing between SVN, GIT, Mercurial. Reading into those options it seems the world is divided. Each has their pro's and cons.

We do want to keep everything on-premise though, we know that much.

Currently I'm thinking of this:

PHPStorm
dev one ----\        Server              Server          Server
             ------- Development ------- Staging ------- Production
dev two ----/        Internal            External        External
                     |_ GIT (VCS)
                     |_ GIT hook (CD)
                     |_ Apache, etc

I'm wondering if there are experienced developers around that can share some of their ideas and knowledge on the topic.

update (2 days later): After weighing VCS's we went with GIT instead of SVN. TeamCity gave some challenges concerning compatibility with our network, so for now we went with a simple GIT hook for CD. We will look into CI some more later.

With GitList copied to an intranet site, we also have a nice on-premise lightweight web GUI for GIT. This makes it easy to keep track of projects and pushes outside of IDE's.

Answer 1

A version control system is a must now, if it wasn't already as a single developer.

It was. A VCS is mandatory for a team of one developer or more. It is so simple to set up, thanks to GitHub and similar services, that there is absolutely no excuse not to have one. Even if you're working on your own on a project, you should version your code, because:

• You can just do something wrong with the code, and discover it only once in production (even if you have a lot of tests). In this case, without VCS, you're on your own to figure out what exactly you modified and how you can recover the working version (all this under pressure because the application is not working on production).

• You can find yourself in a situation where you started something, and discovered that you're on a wrong track, the only solution being to erase all the changes.

• The business may need you to do a modification fast, while you're working on another feature. With a VCS, you just stage your changes, work on the modification, and then go back to the state where you were interrupted. Without, you'll have to do it manually, and you'll likely make a mistake and lose code.

But this also means that I can no longer simply upload to a development server via FTP up on hitting CTRL+S.

Why, was it what you did until now? This creates another series of problems, and means that humans interact directly with the servers. This creates a risk of losing those servers at any moment, because humans are prone to errors.

I suppose this is where CI (continuous integration) comes in?

Or, in your case, continuous deployment. Essentially, as soon as you commit something, an automated process runs the basic checks (such as style checking), then runs the tests (which can be a multi-stage process depending on the number of different types of tests you have), and if everything looks good, deploys the changes to production.

If you want to keep is simple, you can do it with a simple script. Or you can use a complete product which does that for you, if you know how to use it.

This also means choosing between SVN, GIT, Mercurial, etc.

Just pick one. The choice is not that important. Someone in the comments recommended Git; it is indeed a perfectly valid option, and comes with lots of tools, including GitHub Desktop, if you're using Windows or MacOS; the huge benefit of GitHub Desktop is that it hides a lot of Git complexity and is therefore very practical for the beginners. Also consider GitHub, which is one of the most popular hosting services for the source code, including private repositories.