1

Our company has started development of own systems "in-house". We already got couple of developers, who will be responsible for writing code in Ruby/RoR.

We are currently discussing infrastructure, and I would like to ask: should we develop everything on local machines, then put it to test server and later to production, or develop everything on a development/test server, then publish it for testing and later to production?

Just an update to the description above: under "local machines" I meant developers' desktops and this test/development server is a machine in our office.

1
  • Will multiple developers be working on a single Rails project at the same time?
    – John Lyon
    Aug 1, 2012 at 6:58

3 Answers 3

2

You need development server, if team has more than 3 members. For 2 developers - local machines is enough. Development process always goes on local machine, and on development server - developers check, if project ready for test.

Test server usually used for review changes by testers/customers/managers.

And after reviewing product on test server - you can push it to production.

In other words, if one developer, developing project for himself - he doesn't need both - development and testing servers. Only local machine and production. If he has client - he needs also test server. And if he has other team players - they need development server.

4

What benefit would you gain on developing on a test server? I can't imagine anythning. It would make it almost impossible for several developers to develop simultaneously. It would also make it impossible to do any testing while developing.

What you want to do is everyone to develop on their own machine. After each commit to version control, you have Continous Integration server that checks out the code, runs tests and deploys it to test server. CI-server and test server could be the same probably. "Ci-Server" could be as simple as some scheduled script that polls version control and runs your rake tasks, but setting up something like Jenkins is so easy I wouldn't bother.

1

It depends...
In my company we have developers, architects, and project managers. For every project we have a Definition of Done which says:

  • Before commit, developers should test their changes locally to make sure that everything works ok in the latest versions of IE, FF, Chrome, and Opera.
  • If everything is ok, commit changes to the SVN
  • CI script will automatically deploy changes to the test server
  • When User Story is marked as resolved, QA tester (or PM in our case) tests the application on User Story level
  • If everything is ok, PM marks the User Story as QA verified and notifies the client
  • Client tests the application, and if everything is ok, he approves changes so we can deploy them when sprint ends

Sometimes the test server is not enough so we have the staging server as well. The reason for this is because we don't want to stop our development while client is testing our application.

1
  • This is our approach in my Vanderbilt Department, though we have fewer people doing the different tasks mentioned here. If the user community is large enough, as staging server is worth having so development is not slowed down while end-users validate developed code. Thus, we have test, staging and production.
    – thisfeller
    Aug 1, 2012 at 13:06

Not the answer you're looking for? Browse other questions tagged or ask your own question.