Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <blockquote> <p>1) What distinct servers exist with respect to the development process? What is their purpose?</p> </blockquote> <p>In my experience, the only <em>concept/idea</em> that should matter is that all the environments (servers => development, staging, production) should be if not exactly alike, similar with regards to OS, web server versions, service packs, patches, hotfixes, etc. Now, it may or may not be feasible to have a minimum of 3 (or more) distinct environments, but this <em>tends</em> be the norm from my experience. In terms of hardware, as long as their <em>very</em> similar or identical it shouldn't pose any problems down the road.</p> <blockquote> <p>2) Where is your master source repository?</p> </blockquote> <p>Isolated from internet access and <em>heavily</em> guarded. Lots of firewall rules to protect it from undesirable attempts at gaining access. Only developers in-house should be able to access the repository.</p> <blockquote> <p>3) Where is development work done?</p> </blockquote> <p>In larger projects or in organizations, development tends to be done locally on a programmer's computer or with the aid of source repositories (SVN,CVS,VSS,etc.) a <em>copy</em> of the work is done locally. </p> <blockquote> <p>4) Where is testing done?</p> </blockquote> <p>Some people test in their "development" environment, others do testing in "staging" which to me makes a little more sense. Pick one of the two and just stick with it. Personally, I think staging is the place to test to avoid version changes if developers are making changes to development.</p> <blockquote> <p>How do you organize your servers for development of relatively small websites, each with a little bit of unique code?</p> </blockquote> <p>Basically, web shops organize their environments as: development=>dev, staging=>stage, production=>prod. Developers work locally on their own machine, and once their additions/changes are finished they commit the changes to the source repository. Certain shops do something called CI (continuous integration) so after every commit a developer makes, the CI server automatically rebuilds to the site. This helps developers/testers to see if anything broke from a developers changes. </p> <p>Typically these changes are published to their dev environment for all developers to work with. When the developers get to a certain milestone/checkpoint and want to start testing they "promote" the version of their site to staging environment for testers to hammer away at while developers can continue to work in dev.</p> <p>Once everyone is content with everything in staging, they promote the version in staging to prod. Changes should <em>only</em> flow one way: dev->stage->prod. If you want to make a change to production, start from dev then test in staging and then promote to production. It's a pain but it keeps things consistent and prevents from numerous headaches. You'd be amazed how many companies just make changes in production and months/years later they're having problems syncing environments when just following protocol would've saved them a lot of pain.</p> <p>If you're referring to your work as "small" as in simple or not complex beyond some dynamic pages and some database calls, I'd say try to go for 3 environments but you could probably "get away with" 2 environments (staging and production). You could make your own computer the so-called development environment.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload