Jump to content

Plastic for Web Development - Success


hampsterx

Recommended Posts

Hi Folks,

Just want to detail one Plastic setup that is suitable for many web development teams, when I first started looking at plastic it wasn't entirely obvious how to utilize plastic for web development as most of the talk seems to be around compiled applications.

Our team is all based in the same office, we use a single web development server and a development database server. If we need to work remotely we use VPN. Our codebase consists of around 7k+ files (not super large but not trivial by any measure) and is a mix of legacy (spanning nearly 10 years back) and new code. The server requires a little bit of configuration so it's simpler and easier for our developers to utilize a shared development server.

Each developer has his own shared (mapped network) folder on the server which is their plastic workspace. Each folder is then mapped to a virtual host on the webserver. Each developer then has a url like http://tim.devServer which is therefore running a copy of their code on the shared web server. We have a couple of shared folders (/media, /temp) that are "alias" mapped to a shared path.

We then have a trigger that updates a workspace on our staging server so that when the developer merges to /main branch it updates this server ie auto deployment.

That is the gist of it really.

Notes:

- local/remote files/syncronization. At a prior company (PHP Startup) that also utilized subdomains we used Netbeans IDE as it has a file syncronization option. Eclipse IDE has a plugin for this feature but its unreliable, also experimented with several sync tools but ultimately decided to use mapped network drives for simplicity. Only issue is its a tad slow when you need to search over the codebase, ie takes a minute or so to search, its a small annoyance I can live with.

- we dont use labels. We probably should but we don't. Our codebase is continually being tweaked.

Extra Stuff we have developed

- On the website header/nav we read in the .plastic/plastic.workspace file and parse the branch, this is shown along with other developer/debug information to aid the developer.

- testing subdomains. eg alpha.devserver. We have a number of these that developers can hijack to check out a branch and have it notify staff (management, tester, other developers, stakeholders etc). This allows a developer to park a branch so it can get tested at some point and not hold up the developers main subdomain.

- Deployment to Live. we have another script to get our Live server up to what staging server is up to. Using the "find" command in plastic it shows a list of branches/checkins and files that will be updated. At a later point we might lock this down and force ourselves to use the staging server a bit more but for now any developer can run this script.

-----------

Ok thats all, please feel free to ask questions and I'll try to elaborate as best I can.

Long live Plastic,

TiM

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...