14

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.

dole
  • 343
  • 2
  • 6
  • 23

9 Answers9

9

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.

Rudi
  • 19,366
  • 3
  • 55
  • 77
8

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.

Navi
  • 8,580
  • 4
  • 34
  • 32
  • 1
    +1 for your actual development environment but don't forget source control with it. No amount of backups or different environments replace source control. – Beth Lang Jan 22 '11 at 06:50
5

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.

foo
  • 1,968
  • 1
  • 23
  • 35
  • which software is used in the industry to keep the track of the bugs, improvements, tasks, items separately. Now I'm using mantis for tracing the bugs, but what about the other "things" which have to be managed? – dole Jan 23 '11 at 12:16
  • The issue trackers I've found in productive use are capable of managing all mentioned items. Usually, you assign a task a type (like any of the above), and can sort and filter depending on type, status, importance, how long it has been open, and so on. Check out some products like the ones I've mentioned and linked to. - There are also more specialized tools for project management, which keep track in a different way and are suitable for *planning*, scheduling and estimating cost, but that's getting away from the original question here. And many trackers do part of this already. – foo Jan 24 '11 at 08:47
  • To put it in simpler words: use the same tools. You can file "todo" items just like a "bug", they get a different label to sort them by but you can use the same software and interfaces. – foo Mar 20 '11 at 20:01
3

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.

JoshuaDavid
  • 8,861
  • 8
  • 47
  • 55
  • your advice about using subdomains is really cool, but I didn't understand the thing about nightly scripts setup. Can you provide me some links to read about that? – dole Jan 23 '11 at 12:08
  • 1
    @dole - I use psftp.exe (http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html) in an AutoIT3 script (http://www.autoitscript.com/autoit3/index.shtml) ... Here's a tiny example... there are only 2 lines you'll need in the AutoIT3 script: Dim $cmd = "psftp.exe username @hostname -bc -pw password -P 22 -b ftp_script_filename" RunWait(@ComSpec & " /c " & $cmd) The ftp_script_filename parameter is just the series of ftp commands that you want to run, ie, to login, change to the folder, send the file, etc – JoshuaDavid Jan 23 '11 at 22:15
  • sorry about the mess on the prev comment... line break before "RunWait" – JoshuaDavid Jan 23 '11 at 22:22
2

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.

BillThor
  • 7,306
  • 1
  • 26
  • 19
1

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.

ern0
  • 3,074
  • 25
  • 40
1

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).

acconrad
  • 3,201
  • 1
  • 22
  • 31
1
  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
Emanuel Landeholm
  • 1,396
  • 1
  • 15
  • 21
1

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

Knubo
  • 8,333
  • 4
  • 19
  • 25
  • ty for your tip. Yesterday I've heard for the first time about mind maps and I think it is a great concept, but I'll like to see some example about how it is used in software dev. I've played a litle, but I'll like to see how the pro are using it and to learn from them too. Any link, blog, book about that? – dole Jan 23 '11 at 12:04
  • Thank you for mentioning Mindmaps. From my experience, mindmaps are excellent for the early planning stages, when you try to get a grip on the project, collect data and especially get *people* to share a common view. Also, if the project changes, mindmaps can be handy to adjust and refocus. But I find mindmaps *not* useful, however, when keeping track of issues and bugs. I think this tool suits a different purpose. – foo Jan 24 '11 at 08:41
  • I added a mind map example on how I do use mind maps. I bet there are others that does similar stuff and probably use it in even better way than me. Have a look around the web and see what you can find. – Knubo Jan 29 '11 at 13:25