how do you organize your programming work

Question

I'm a newbie in the field, but in the near future I have to develop an application for a friend(I've already did some work of the app and the friend is happy).

I assume that I need 3 places to store my work, but I'm not sure if this is the best approach. I need your advice, opinion, link,book, blog about this subject.

I plan to have:

1. a place where I develop the application
2. a place where I keep a back-up of the application
3. a place with the application ready for use

I'll use git in the development stage, but for the later I don't know what tools to use, or which are the good practices. Can you give me an advice?

PS: at this moment I'm using cakephp to build some webapps, but I play with C++ from time to time too.

Answer 1

1: a place where I develop the application

This would be you local git checkout.

2: a place where I keep a back-up of the application

Do you mean the sources or any compiled result? For the sources you can

1. Use a public service like http://github.com or http://gitorious.org as backup system. I recommend this if you don't mind to use a service which is not under your control.
2. Set up a own git server (a linux box with sshd and git installed is sufficient). You need to be aware that there are some pitfalls when you set up a remote repository (the repositories should be bare, and you need to set the permissions right when there are multiple unix users which should be able to push into a repository)

With either way you git push your commits into the remote repository to have a backup of your work.

3: a place with the application ready for use

There is no definite standard on the storage of compiled results. Typical the results are stored with a defined numbering scheme on a file share/web server/whatever.

I'll use git in the development stage, but for the later I don't know what tools to use, or which are the good practices. Can you give me an advice?

As @Navi already said, an automated build tool is a big plus. A best practice is to have a one-command build, which means that you need to run exact one command to build the complete software after a checkout.

You should also consider a continous integration system, this is a software which monitors a central source code repository for changes and automatically builds the software in a clean room environment when it detects something new. CI systems are especially handy if there are many (>1) people working on a software product, since they can show broken builds very quickly.

Answer 2

A lot of people have talked about having an issue/feature tracker for your work. If it is only you that is doing work I recommend you to have a look at FreeMind.

Mind mappings is an excellent way of keeping track of the tasks and things you need to do for you project. Write down any thought that you want to keep, but you don't have time to do right now.

Edit: I added an example for a task for an expansion in my open source project:

Mind Map example

Answer 3

Most good advice has already been given:

• Use source control / revision control. And backups. Really, really do this.
• have separate instances for development, testing, integration/staging and production. If you lack the hardware, virtualize - there are some good commercial solutions, but even Virtualbox (for free) will often do the job.

In addition, I also recommend

• Make backups of your stable instances at milestones. When it works, keep a copy.
• Use an Issue Tracker like JIRA, Bugzilla or similar. At the very least, have a text file with a ToDo list and a good grep.
• Place marks in your code like @TODO and @FIXME wherever applicable; most IDEs I know will find these automatically and present you a list of those. This may or may not integrate with the tracker.

I find it important to keep track of what's left to do and how important it is, differentiate between bugs, improvements, necessary tasks and nice-to-have items and so on. It's easy to get Lost In Development and forget stuff - programming requires you both to dive deep into the inner workings of code, and to keep the overall structure in mind. You'll need something to keep your mind free from all those "and I'll have to do this as well" things. Sticky yellow papers don't work that well, nor do writing pads, since with more than, say, 50 items, paper makes it hard to keep track.

There is software for that. Use it.

Answer 4

1. External version control (github, bitbucket)
2. Eg. rsync to Dropbox folder
3. Production stuff should be generated programmatically from some tool version controlled in step 1

Answer 5

Store your code on http://www.github.com. If you need the code to be private, you can create a hosted, private repository for a nominal fee, which will satisfy the first 2 of your requirements.

If you are looking to store the code and host the site, there is a cloud services company called PHP Fog ( http://www.phpfog.com/ ) which will host the code and have it ready to use (requirement 3).

Answer 6

Here's the best practice for high productivity, yet straight-forward enough for a newbie.

1. Setup a local dev environment. Use a VCS like TortoiseSVN or ideally use something that fully-integrates with your IDE. I use Aptana with Subclipse to develop PHP apps.

2. Setup nightly scripts to auto-backup your VCS remotely.

3. Get a remote dev environment setup (ie, dev.mysite.com). Use for live server testing, client proofing, UI feedback testing, etc.

4. If there's a need, setup a staging server (stage.mysite.com). Use for live integration testing, feedback testing, etc. If your projects are small enough you can usually skip this stage and just use you dev environment for integration testing.

5. Setup a production environment (www.mysite.com)

Don't over-engineer your workflow... your time is precious. For now, I would say start with this, get some experience under your belt and then you'll know how to refine your workflow.

Answer 7

I have found a minimal set of code is development and release. Some sort of version control is essential. I use HEAD for development, and branch on release. Backup your repository, or at very least have it on a different disk from the one(s) used for development and building.

I prefer to have three sets of code: development, testing, and release. Each should have an automated build environment. These are build environments. For development, only a single set is needed.

• Release code is used for changes to released code that are applied prior to the next release. Any changes done here are either merged back to development. or redeveloped (in case of a quick fix).
• Testing code is release for testing. This provides a relatively stable environment for testers. Builds are usually tagged, but not branched. The tag is used as the base for the release branch.
• Development should build automatically at least daily. This ensures the code can build outside the development environment.

You can use GIT for development and production, but the workflow is different than you would have with CVS or subversion. Look at the ProGIT online book to understand the flow.

Avoid coding in the environment to the application. Any environment dependencies should come from the configuration of the environment. It is nice to display some indication of the build and environment in the interface.

Answer 8

Quick-and-dirty workflow for single developer, who don't use any version control sw:

• actual production: the exact copy of user's version,
• release: the ready-to-ship version (should be deployed, but haven't done yet),
• work version: which you're working on,
• backups: the backup versions should be in working state.

If you're using a db, there would be one database versions for each program version.

Answer 9

Common practice is to have a dev, test, integration test and production environment. Integration test and production will be more or less the same.

I suggest that you use some kind of build tool as well. It's not clear from your question what kinds of platforms / technologies you are using, but there probably is one suitable for you.

If you are using Maven, then the convention is to have the distinction between stable releases and snapshot experimental versions.