I recently watched The Social Network, and this might be a stupid question, but how is it possible for multiple people to work on one website? I mean, if they're working on the same page, how is that possible? And also, is it possible to upload files to an online host without making them live?
Very few websites consist of just one "page" and, for cases where multiple people would work on the same page, most revision control systems have mechanisms built in for merging the changes back together into a unified file.
Multiple persons working in the same files: Source control
Without making them live: Development servers & databases, which are not the same branch as the real website.
They need some kind of manager.
Typically, teams are broken up into segments that should never interfere with each other (famous last words). For instance, if the foo API depends on helpers from the people who code in C, the breakage should (never happen), but if it does, it happens because the helper app doesn't understand what you are passing to it.
That is a classic case of the right hand not knowing what the left hand is doing, which clearly illustrates the fault, which is probably mine.
If you push code without first pulling and resolving merges (while breaking what the other dev did by just removing whatever you didn't write), prior to communicating with others who edit the same, I'm going to dose you with high voltage. After that, I'm going to take you out to dinner (to make ammends for the 1.21 gigawatts) and ensure that you ingest some kind of crazy, disgusting and quite exotic food. Think ... Klingon.
You'll then thank me for that, and never do it again.
Of course you could substitute some sort of normal 'talking to' here, but what fun is that?
You'll probably find that they have developers working on different pages. A template or site master is usually created so that each page has the same look and feel. For example, if the company is using Source Control such as Team Foundation Server, each developer would check in their source code and this will allow the other developers to get their latest changes.
They could either:
- Be programming in an editor via an SSH session (e.g. vi, vim, nano, emacs).
- Be editing through FTP with their IDE (e.g. emacs, notedpad++).
- Using a version control system.
For the last one, people now use distributed version control such as mercurial, git and bazar, instead of centralized version control such as CVS and subversion. For mercurial, check bitbucket.org and google code project hosting, for git, check github, which are sites that host the code for you to share collaboratively without you needing to set up a server.
Developing pages with components VS Pages as a Whole
I've worked on many large scale websites, and the way multiple people work on the same page is that most websites are portals. In general, many sites like facebook contain many controls, such as photos, ads, little blurb areas, etc, which multiple people will work on. Also, headers and footers are generally broken into their own reusable include file. This breaks the site up into components that can not only be worked on individually, but can also be re-used across multiple sites and areas.
Don't forget that there can also be content management systems that some sites use to serve content so that while you may think something is a web page, it is really this mix of stuff.
Many content management systems will have a preview feature to allow authors to view content before making it publicly accessible.
All of these tools mentioned are helpful, but to me it sounds more like the OP is more asking how people keep from getting in the path of others.
In addition to using tools to solve those conflicts there is usually some division into stacks or tiers to help avoid the conflicts in the first place.
With the stack approach you have each person working on an unrelated feature (one person may be doing account sign-up and one may be doing content submission). There will be some conflict where the two may cross (user records in this example probably) and that gets handled as part of the merge to the next build.
With the tier approach someone is building all the innermost bits, when they get one portion finished another person writes the bits that sit atop those and so on. the conflicts generated here are usually when something has to be returned to on a lower tier for some later modification that could affect the next tier above and are handled in a similar manner before the next build.
The part about files promoted but not live has a wide variety of answers/implementations, but a separate server to preview on, a specific preview mode, or a user class or entitlement that pulls the bleeding edge version while regular users get the stable version are the ones I tend to see most often.
To answer the second part first, one way to upload files without making them live is to give them a name that won't be linked to. E.g. to make a new version of an
index.html page, upload it with the name it
index2.html, then visit
http://yoursite.com/index2.html and check that it works OK. Once you are satisfied, rename it to
index2.html whose only difference is that it points to the new image.
A professional programmer would always have a test system to work on, then upload to their "online host" once they are happy with the changes. You can set up a web server on your computer that will only serve pages inside your local network. Of course you could also use a separate computer, or (as I do) a virtual machine running on your main computer.
When multiple developers work together, each would have their own test system to work on, then upload their changes to a version control system that keeps track of all the changes from all the different people. See the git parable for how this works.
The version control system makes it easy to see who changed what and why. This can be checked over by whoever is in charge and then merge it into the master, and hand it over to the testing / QA department. Once they have fully tested the new features, they will approve it for uploading to the live site.
First thing to establish is that many sites aren't a collection of static pages that are worked on by one or more people.
The pages that you see as a visitor don't exist on the website to make changes to as in such sites they are automatically assembled on-the-fly by a content management system - software running on the hosting server, using content that the website owners have produced. The CMS assembles the page from the content laid out using template files (CSS and CMS's own config files) and the resultant page is served to your browser.
The site owners make changes to the content and the layout templates rather than static pages. Leading on from that your answer depends on the type of change and the role of the person doing it:
- a site public user, posting a blog or comment
- if you are changing the content on the site (content producer role, e.g. journalist working for the website owner) or
- adding and changing functionality of the site (site developer working for the site owner).
Drupal is a free and powerful content management system that provides multi-user management to handle content updates which in turn affects what is seen by visitors on pages. Drupal will also provide means to alter the behaviour of the pages, e.g. how they are laid out or if commments on an article can be posted, addressing the 1st and 2nd types of change. If doing the changes in Drupal these will be stored in a SQL database. Drupal provides some versioning/revision control of content.
A full version control system is needed for more involved site behaviour changes, the 3rd type of change e.g. introducing more features, receiving updates from Drupal, or fixing bugs on own added code, then this means changing the code and as others have posted here. Version control systems such as GIT, Subversion or Mercurial - all free - are used to manage the changes made by several developers of the site.