Most developers would assume that all other developers know what source control is, and that they use it. It's probably impossible to know this for sure, as most software is closed source and written behind closed doors. I tried to do a bit of research and came across an old StackExchange post (from 2011). It seems back then that a lot of companies, including banks!, were not into the whole source control idea. Who knows what it's like now, but I really hope source control has become much more widely adopted.

When it comes to continuous integration, source control is vital. I'm not going to spend any time explaining what it is, Wikipedia has a pretty comprehensive article. Personally, I'm a huge fan of git, but I have used SVN, CVS, TFS and a little bit of SourceSafe in my career. At university, my idea of source control was a copy of the source folder at regular intervals, oops :) Whichever specific source control tool you prefer is up to you, I just hope you're using something.

I mentioned in an earlier post that continuous integration involves regularly integrating your changes with that of the team and making sure everything still works. Honestly, I can't think of any way to manage this without source control.

Let's take a moment to consider the case where source control is not used:

1. The project code is stored on a network share, so you make a copy when you arrive at work
2. You work on something for about an hour and it's compiling and working on your machine. But how do you know it will work when merged with your colleagues' code? Come to think of it, how would you merge with your colleagues, considering they're all working on their own copy, on their own machines.

We can see pretty quickly that CI is just not going to happen without source control. We can also see pretty quickly that the lack of source control makes it near impossible to do team development.

Now, let's look at the same scenario using source control (specifically git).

1. You arrive at work and pull the latest changes from your company's Github repo.
2. You work for an hour and everything compiles and works, so you commit it to your local repo
3. You pull from Github again to ensure you have your colleagues' latest changes, then merge your changes into theirs.
4. You now build everything again locally and everything still works, so you push the changes to Github.

In a most basic way, you are now practising CI, you are integrating your changes regularly and confirming that they all still work (its not that hard is it?)

Now, there may be cases where it's not possible to confirm that everything works locally, or you have a test suite that takes 45min to run so you can't realistically run it before every push. You'll also want to make sure that someone doesn't accidentally push broken changes to your central repo. For these cases we delegate the integration, compiling and testing to another machine, but we'll cover that in another post.

In summary:

1. Please, please, please use some sort of source control. Even if you're working alone, do it to get into the habit and learn how it all works.
2. Commit your changes (locally) regularly
3. Fetch and merge your colleagues changes regularly
4. Push your merged changes regularly

If you're using git, I'd recommend the following services for storing an offsite copy of your code (another huge benefit of using source control):

• Github - Only free for opensource repos
• BitBucket - They allow free private repos
• Assembla - Not free, but also provides some nice project managment tools.

Next time I'll cover setting up another machine to do the CI for you.