0

We have a small team currently working on numerous projects. We originally started out as a two person team and jumped in head first without any kind of source control. We currently break numerous best practices and do development on live sites (yuck, I know).

We're in the process of fixing this issue incrementally. The first step, which we're in the midst of implementing, is separate development and production instances of sites and internal processes for pushing code from dev to prod and how to handle situations that require rolling back those changes. This still leaves us with the issue of more than one developer working on the same file and overwriting each other.

The next step, and this is where my question comes in, is implementing a much larger, sweeping change, and implementing source control. Obviously, source control works best when each developer has their own local repository. My searches have yielded mostly scenarios that involve a remote SCM server and each developer pulls down a copy to their local machine for development. For a myriad of reasons, which I won't get into here, development on local machines won't work for us, so, please don't respond with questions about why we don't just do development on local machines.

So, what I'm envisioning is a remote development server that can serve multiple functions. First, it can act as the staging server for our projects. Second, it can act as the development server for all our developers. Their IDE, obviously, would still be on their local machine and they'd connect to the remote development server as they've always done. The rub is integrating source control into the mix.

Let me throw out the disclaimer that I know enough about source control to be dangerous, but not enough to actually implement anything.

With that said, here are my thoughts.

1) The application server supports instances, so staging and each developer would have their own instance.

2) Staging and each developer would have their own root folder on the server and sites within each root folder would be accessible via subdomain, like so:

D:/Dean/...
    .../Inetpub/wwwroot/example1.com/wwwroot/     --->  dean.example1.com
    .../Inetpub/wwwroot/example2.com/wwwroot/     --->  dean.example2.com
    .../Inetpub/wwwroot/gaggle.com/wwwroot/       --->  dean.gaggle.com
    .../Inetpub/wwwroot/yoohoo.com/wwwroot/       --->  dean.yoohoo.com
    .../Inetpub/wwwroot/bong.com/wwwroot/         --->  dean.bong.com

D:/Sue/...
   .../Inetpub/wwwroot/example1.com/wwwroot/      --->  sue.example1.com
   .../Inetpub/wwwroot/example2.com/wwwroot/      --->  sue.example2.com
   .../Inetpub/wwwroot/gaggle.com/wwwroot/        --->  sue.gaggle.com
   .../Inetpub/wwwroot/yoohoo.com/wwwroot/        --->  sue.yoohoo.com
   .../Inetpub/wwwroot/bong.com/wwwroot/          --->  sue.bong.com

D:/Jorge/...
     .../Inetpub/wwwroot/example1.com/wwwroot/    --->  jorge.example1.com
     .../Inetpub/wwwroot/example2.com/wwwroot/    --->  jorge.example2.com
     .../Inetpub/wwwroot/gaggle.com/wwwroot/      --->  jorge.gaggle.com
     .../Inetpub/wwwroot/yoohoo.com/wwwroot/      --->  jorge.yoohoo.com
     .../Inetpub/wwwroot/bong.com/wwwroot/        --->  jorge.bong.com

D:/Li/...
  .../Inetpub/wwwroot/example1.com/wwwroot/       --->  li.example1.com
  .../Inetpub/wwwroot/example2.com/wwwroot/       --->  li.example2.com
  .../Inetpub/wwwroot/gaggle.com/wwwroot/         --->  li.gaggle.com
  .../Inetpub/wwwroot/yoohoo.com/wwwroot/         --->  li.yoohoo.com
  .../Inetpub/wwwroot/bong.com/wwwroot/           --->  li.bong.com

D:/Staging/...
       .../Inetpub/wwwroot/example1.com/wwwroot/  --->  staging.example1.com
       .../Inetpub/wwwroot/example2.com/wwwroot/  --->  staging.example2.com
       .../Inetpub/wwwroot/gaggle.com/wwwroot/    --->  staging.gaggle.com
       .../Inetpub/wwwroot/yoohoo.com/wwwroot/    --->  staging.yoohoo.com
       .../Inetpub/wwwroot/bong.com/wwwroot/      --->  staging.bong.com

Each of these root folders would contain all resources necessary to make these sites function -- code libraries, user-defined function files, custom tags, components, third-party assets like Bootstrap, Font Awesome, etc.

Additionally, each of these root folders will act as the home for all "local repositories" for each developer and the staging root folder will act as the home for finalized code for QA before deployment to production.

3) A single instance of IIS would support all of this. As developers are tasked with writing web code and not with managing any aspect of IIS, how requests are parsed prior to handing it to the application server for their code to process, etc., I don't see any issue with IIS being a single instance (in fact, it makes it easier to enforce similarity of environment).

4) I haven't settled on a source control solution yet. I'm leaning toward some manner of DVCS like Git or Mercurial.

5) It appears that separating the repository from the IDE so they're on separate machines is somewhat problematic. As seamless integration with source control within the IDE is the surest way to gain adoption, I'd love to be shown my understanding is incorrect.

So, after all this, my question is...

How can we have source control and have developers working on a remote development server and have it seamlessly integrated into their IDE?

Also, a helpful (or annoying, depending on your perspective) caveat is we're a ColdFusion house and use ColdFusion Builder 2016 (which is Eclipse, under the hood) so whatever solution there is would need to work with that. We're also running Windows Servers and a mix of Windows and Mac local machines, if that affects the solution you'll suggest.

Improve this question
17
  • 1
    You could do this yourself with Git and a Windows Server, with people remoting in and having the appropriate permissions only on their shares, but I guess the bigger question is why? If the developers have local machines, they can develop on them. If you don't trust them, then there's no point in giving them any code. programmers.stackexchange.com/questions/10736/…
    – mgw854
    Oct 20, 2016 at 0:16
  • 1
    "development on local machines won't work for us" - delirium and stupidity and lack of understanding... technically anybody anytime can write code into local file in local IDE. Deploy (more or less smart) in another question and separate task
    – Lazy Badger
    Oct 20, 2016 at 1:10
  • 1
    @OregonJeff: What does the workflow currently look like for a developer when he wants to make a change that is only visible in his own development environment (for example, to test something that isn't ready to be shared with others).
    – Bart van Ingen Schenau
    Oct 20, 2016 at 11:12
  • 1
    To be more specific than that, how do developers work on a local IDE yet change remote files? Are they using shared drives? Or do they just have a local workspace and copy the file over once they're done? I think you need to go into more detail about the current process to get a good answer.
    – kdgregory
    Oct 20, 2016 at 11:32
  • 1
    It's critical to understand the constraints of a problem. After some Googling, it appears that you're using ColdFusion's RDS Fileview to access files. If you'd mentioned that in your original post, rather than a generic "this is what we want to do" it probably would have gotten better answers. And, to be honest, I think that as a specific question, it's more appropriate for SO rather than this site.
    – kdgregory
    Oct 21, 2016 at 13:13

2 Answers 2

Reset to default
2

Windows Server is perfectly capable of handling something like this with some manual intervention (or better yet, PowerShell scripts). I'd suggest using Git, because I know it can handle the situation you're dealing with (and it's generally well regarded for handling multiple users). Move all of your source code into Git, which you can host on your server. I'd lock down everything related to the master branch once you set it up so that it can only be merged into by a build/deployment tool.

Here's the steps I'd follow:

  • Create user accounts for each user on the server
  • Create a directory for each user, provisioned with the correct permissions
  • Clone the repository into each of the new directories
  • Create an app pool per user in IIS
  • Create all the applications per user in IIS and assign them to the app pool
  • Share the user's directory as a network share
  • On the local machine running the IDE, use the network share path as the project folder

This should get you everything you want. As a network share, the developer can interact with it as if it is local. The one caveat I've noticed is that network shares don't always trigger the same file change events as local folders, which can make certain hot reloading tools not work.

Improve this answer
7
  • Is the network share necessary for the local Git client to work on their machine against their remote "local" repository on the dev server? If not, I'm worried that network shares are notoriously unreliable and often have fairly serious lag issues.
    – OregonJeff
    Oct 20, 2016 at 0:50
  • They certainly can be problematic, but distributed source control is meant to run on local machines. If the source is elsewhere, you still need to expose those files locally somehow. A network share is the only way to do that seamlessly.
    – mgw854
    Oct 20, 2016 at 0:53
  • I wonder if a product like WebDrive which makes it possible for FTP connections to function as a mapped drive would make this more seamless. Any thoughts on that approach?
    – OregonJeff
    Oct 20, 2016 at 1:02
  • 1
    Everything you do is going to be inherently unreliable because you're using some sort of network. FTP isn't really more reliable than CIFS. I'd also caution you against trying to tack on solutions to this problem; I'd again humbly submit that the problem you're dealing with isn't the one you're trying to solve.
    – mgw854
    Oct 20, 2016 at 1:09
  • What is the problem I'm dealing with then?
    – OregonJeff
    Oct 20, 2016 at 1:21
0

Short answer

Easy. Any Windows network-share, announced in LAN, can be mounted as additional local drive on any host in LAN and resources on this share will be presented as local to local OS. Just do it

Longer answer

Microsoft SMB Protocol is still the poorest and worst choice over alternatives - especially for case more complex, than just "share text/plain files". If you can, it will be better to invest some time, attention, money into investigation and deploy SMB-alternatives (point one, point two) from the very beginning, than have disasters, interrupting business

PS: from my POV, local repos with remote bare-repo still is the most reasonable and natural way with no headache and transparent workflow without carefully scattered garden rakes in the grass

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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