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.

OregonJeff
  • 103
  • 3
  • 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. http://programmers.stackexchange.com/questions/10736/how-to-manage-a-closed-source-high-risk-project – mgw854 Oct 20 '16 at 00:16
  • I'm not interested in discussing why we're going this route, why doing development locally doesn't work for us, etc. I'm interested in how to make this particular approach work. – OregonJeff Oct 20 '16 at 00:23
  • As such, what does your suggestion of "do this yourself with Git and a Windows server" accomplish regarding integration with the IDE? Please expand. – OregonJeff Oct 20 '16 at 00:29
  • 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 '16 at 01:10
  • Do you have **good** Network Admin in team? Or can you hire such boy? – Lazy Badger Oct 20 '16 at 01:11
  • Can you offer an answer that works within the constraints I've outlined, @LazyBadger? – OregonJeff Oct 20 '16 at 01:42
  • 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 '16 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 '16 at 11:32
  • @kdgregory, the IDE we use has specific hooks into the application server for remote file editing. It exposes directory structure and file listing. Opening a remote file pulls its contents local into the editor and subsequent "save" commands cause any changes to be saved to that file. It's not really any different than using Eclipse's Remote System perspective to connect via FTP and edit remote files that way. – OregonJeff Oct 20 '16 at 19:52
  • @BartvanIngenSchenau does my answer to kdgregory answer your question, too, or do I need to expand on it somehow? – OregonJeff Oct 20 '16 at 19:54
  • 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 '16 at 13:13
  • Given that constraint (and this is not an answer because I don't know Windows or CF), your first step should be to see if ColdFusion Server supports any source control systems *other than Visual SourceSafe* (which more Googling told me was one option, but is one that you don't want to use). If it doesn't, you're going to need some way to trigger checkins remotely, which would be something that a Windows developer could help you with. – kdgregory Oct 21 '16 at 13:16
  • Finally, I would probably *not* use Git or Mercurial, although that depends on whether you're just managing source code, or libraries and other binary assets. A distributed VCS keeps its entire repository in each working directory, and multiple versions of binary files will quickly bloat the repository. A centralized VCS only stores the current versions of those objects in the working directory. – kdgregory Oct 21 '16 at 13:18
  • @kdgregory Apparently you're not aware that Git, at least, stores its data very efficiently (with compression), to the point that a Git working copy (with history) is often smaller than a SVN one (without). – Marnen Laibow-Koser May 20 '18 at 18:15
  • @MarnenLaibow-Koser - wow, so now you're stalking me. There's a word in my comment that you might have missed: "binary". The sorts of things that are generally called "binary" files (images being most common) don't compress well because they're already compressed. – kdgregory Jun 01 '18 at 10:50
  • @MarnenLaibow-Koser - If you don't like my answers, downvote them. If you think you can write a better answer, do so. If you really feel the need to seek out the comments I've made and contradict them, feel free to do so as well, but I'm done responding. – kdgregory Jun 01 '18 at 10:52
  • @kdgregory I’m certainly not stalking you; I don’t do that. I’m just responding to things I find worthy of a response. I can’t downvote comments, only answers, and anyway, if someone says something that I think is incorrect, I believe it’s more helpful to comment than to simply downvote. – Marnen Laibow-Koser Jun 01 '18 at 15:38

2 Answers2

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.

mgw854
  • 1,818
  • 10
  • 11
  • 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 '16 at 00: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 '16 at 00: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 '16 at 01: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 '16 at 01:09
  • What is the problem I'm dealing with then? – OregonJeff Oct 20 '16 at 01:21
  • Not allowing developers to develop locally. The staging process should absolutely happen on a dedicated server, but an ideal situation is to segregate each developer on their own machine with all the resources that they need. Imagine that IIS stops working on your single server (which I've seen happen when developers "experiment")... now everyone is stalled until it gets fixed. I know you said you don't want to do that nor discuss it, but it's the right answer. I know we can't always chose the right answers in our line of work, and I've fought similar battles before, so I do sympathize. – mgw854 Oct 20 '16 at 01:29
  • We have a few mitigating circumstances that don't permit development on local machines. I realize it'd be ideal, but I'm stuck coming up with a solution that functions within this constraint. – OregonJeff Oct 20 '16 at 01:34
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

Community
  • 1
Lazy Badger
  • 1,935
  • 12
  • 16