Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Is it necessary/recommend/best practice/any other positive to use only one server environment to perform all development, unit testing and QA?

If so, is it then wise/part of Agile to then have only one staging environment before Live?

Considering that this could mean internationally distributed teams of developers and testers in different time zones is this wise?


This is something being implemented by our QA manager. The opinion put forward is that doing all the dev and testing on a single server is "Agile." The staging environment would be a second environment, and then live.

share|improve this question
4  
Why would you need to confine it to a single server? –  Robert Harvey Jun 27 '13 at 21:01
8  
What does team management (SCRUM) have to do with your development / server environment? If anything it would be that the team(s) decide what development environment works best for them and if the team decide that they need separate servers there is nothing in Agile or Scrum that prevents that. –  Marjan Venema Jun 27 '13 at 21:08
    
This is something being implemented by our QA manager. The opinion put forward is that doing all the dev and testing on a single server is "Agile." The staging environment would be a second environment, and then live. –  Matt W Jun 27 '13 at 21:18
2  
Do you (or your QA manager) have any references to the practice of using a single server? I guess you think he's making it up. –  Dave Hillier Jun 27 '13 at 21:44
    
I certainly don't but as he's a professional with years of experience I can only assume he does. I see the dev and test layers as separate from the staging and production layers and, where the team agrees, necessary. –  Matt W Jun 28 '13 at 6:45
add comment

closed as unclear what you're asking by Jim G., MichaelT, GlenH7, thorsten müller, Robert Harvey Jan 14 at 19:28

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question.If this question can be reworded to fit the rules in the help center, please edit the question.

5 Answers

Agile is:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Set up your development environment to reflect and support these principles.

Scrum is a way to manage your work, not your development environment.

share|improve this answer
    
Thank you. I have read the manifesto and could not see any rules relating directly to specific practices which would state clearly "developers and testers should/must work on the same environment." I would like to know how the decision to move a testing layer is a benefit, or if it is nothing more "doesn't look smooth." –  Matt W Jun 28 '13 at 6:47
2  
You're missing the point, Agile doesn't specify what tools/environment you use for a reason, because it's up to YOU to decide what's best for YOUR team. There is no best way of setting up an environment, as every team is different, and instead of trying to fit a square peg in a round hole, agile leaves the implementation specifics up to you. –  Ampt Jun 28 '13 at 12:03
    
Thanks... Your point was exactly what I tried to communicate to the team. –  Matt W Jun 29 '13 at 8:03
add comment

The QA manager might get his idea from the seemingly common interpretation of Agile where a team delivers a completely (QA-)tested product each spring that can be rolled out to the customers and he extrapolated that to reach the conclusion that it can be best achieved with a single development/QA environment.

And it might be one way to implement Agile practices, but it certainly is not the only way. I have worked with scrum in an environment where the development and QA teams were largely separate, and the QA team was the "customer" of the development team. In such an environment, the development and QA teams naturally work on different servers/deployments.

We can't really advise if a single dev/QA server environment is going to work for you. It depends too much on how you are used to work and how well the different people can cope with the occasional broken build.

One thing is for certain: Agile does not dictate anything with regard to how you set up your development (and related) environments.

share|improve this answer
add comment

It is well established in a waterfall environment that the early detection of bugs reduces cost of fixing them. As analogy, you could think of all waterfall stages happening concurrently.

Therefore, a way of supporting that and reducing waste, you could argue that using one development server could cut costs. As soon as the developer has finished, the Testers can begin doing their work. It eliminates the waste of having to deploy the software to a new environment and the waste of waiting time.

Of course, testing deployment in itself is valuable. Having features in a state of development may cause false positives - unfinished features may 'work' and then later regress or testers tell you that it doesn't work when it isn't finished. You have to make this judgement call for our own team. We don't have enough context for a definitive answer.

And in the end, your QA manager doesn't actually have to do the coding himself. In this context he has a 'chicken' role. If your team of developers feel that they can work better or more productively by ignoring him, then they should.

share|improve this answer
add comment

I think teams can work in more agile fashion if they have multiple servers at appropriate levels..

First some assumptions: Two development teams: USA and Pakistan. QA is a separate team and uses nightly build. Development teams are highly productive and do frequent check-ins. They can use a Distributed Version Control e.g. git.

So a developer from Team USA will run unit test on his machine for areas effected by his latest check-in to Local Repository and will then push the changes to the Team Repository. There the complete unit testing suite along with automated functional tests* to be run on Product A. If everything is green then the code changes to be anatomically pushed to Check-Build Repository where integrated tests would run. If still green, then changes to be automatically pushed to Master Repository used for nightly build. That nightly build to be used by the QA next day.

All repositories to have their own application/data/build servers.

*If functional tests are long running then we can have two level of Team Repositories. One for short running tests (e.g. all unit tests, some functional tests) and second for long running functional tests.

share|improve this answer
add comment

Although as Bart says, Agile might not dictate an environmental set-up, the values and principles do indicate best practices where code is aggregated and tested on an ongoing basis. That practice is in direct opposition to the gatepost approach in traditional waterfall environments. Transition through the gateposts suggests an approach is waterfall. High levels of automated integration testing suggests agility.

Bottom Line: You've got to have essentially all of the testing done within the confines of the Sprint to meet any Agile Definition of Done. How the code is Released to Market is up to the business. They can RTM weekly, monthly or quarterly and still claim to be Agile, but they need to maintain a Staging site for code that is Done but not Released.

share|improve this answer
add comment

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