Version control, working with a team, maintaining a staging site, data entry while developing
I know this is a variation of a question that has probably been asked a thousand times, but I'd still like to hear your views on the following:
I need to work on several future projects with a team - I will be a contractor, and the team will belong to a small web agency. There is a chance that another contractor will be involved from time to time. The total number of people actively involved in any form of coding (including frontend html/css/js etc.) in any project, including me, will range from 2 to 4 persons.
I want to enforce version control (for obvious reasons), and my choice is git (with a local Gitlab installation), which I've already set up at the company.
Here's the tough spot: The agency always needs a version of the site running during development (accessible by their client and themselves) for layout checks by the client as well as data entry (by both the client and us). Let's call it "staging", for lack of a better term.
I know this is far from a standard setup, but usually deadlines are so tight that the client (or the agency) have to start entering data as soon as any section of the site is finished. This is the way they've been (successfully) working on dozens of projects so far and I'm not the one to suggest otherwise.
The most satisfying solution I've come up with so far is the following:
Website project (as opposed to WAP), and app_code is your friend.
Common database (via VPN, a bit slow, but generally ok)
Bonobo Git server on staging server, multiple repos (two - one for
staging with Bonobo, one "official" with Gitlab).
Staging server accessible by the client (meaning the website, not the
server itself)
Media folder sync via BTSync or some similar app
So the scenario is that everybody will get their own copy of the site from Git (/bin folder included since it will be a website project and everybody will need any new or updated DLLs), access a common database, share the same media folder contents and only update the staging site with new pushes from time to time.
This obviously has many disadvantages, the main of which is no Web Application Project, meaning less control over things. But it can also be beneficial to the scenario described above.
Any views or ideas on alternative ways of achieving the same result?
EDIT: I've worked with said agency in the past - but I would work directly on their "staging" site (which would be a website, not a WAP, of course). I would work on my own copy (backed by version control) if needed, but their "staging" site was what was visible to them. They would change things there, all of them, accessing shared folders. This approach is, obviously, extremely wrong and cannot go on any more, so I'm looking for a better way to organize work without losing the benefits they have from this approach so far.
We use a very similar setup at the agency I work for, aside from we currently don't have any remote workers, but when we work from outside the office we connect to the shared database via VPN like you mentioned.
We have a normal IIS site setup on our dev or staging server which the client can approve/edit, which gets updated via a push to the master branch to the repo hosted on bitbucket using TeamCity. I'm not sure why you'd need two repos?
I would however strongly recommend excluding the /bin folder just as I would advise against including compiled .css/.js files, only the source files should be in a repo and the build steps should handle the rest. For dependencies not using NuGet (so aren't automatically included in the bin when building) we have a dependencies folder and a post-build task which robocopies them into the /bin folder.
Our solutions have a few projects, one of which is the .Web project containing the Umbraco installation, and others like business logic which keeps things seperated. I'm not sure why you wouldn't be able to have a web application project?
Feel free to ask any questions, hopefully there's a few ideas that might be useful.
This is a very interesting approach. I hadn't considered CI until now.
(You meant to say "recommend against including the /bin folder", right?)
Your approach essentially eliminates the need for a WSP, so yes, with this approach I could definitely use a WAP everywhere. The dependencies folder approach is very clever.
Some questions that are probably easy to derive answers for, just want to ber sure:
Do you use the same DB in your IIS site setup with the one used in development? (Common DB across all dev/staging environments?)
Do you copy the Media folder contents from environment to environment? How do you sync the Media folder? (I'm pretty sure you're not including it to source control :) ).
Yeah, sorry it was late at night! I've edited the post to not confuse others should they find the thread.
In response to your questions:-
We do, I've found it's easiest this way, the only hastle comes when having live environments and trying to sync between that and the staging.
For any sized media folder, we use a virtual folder in our local IIS which points to the media folder on the staging server, this works pretty well when you're in the office or on the VPN and also saves space!
Version control, working with a team, maintaining a staging site, data entry while developing
I know this is a variation of a question that has probably been asked a thousand times, but I'd still like to hear your views on the following:
I need to work on several future projects with a team - I will be a contractor, and the team will belong to a small web agency. There is a chance that another contractor will be involved from time to time. The total number of people actively involved in any form of coding (including frontend html/css/js etc.) in any project, including me, will range from 2 to 4 persons.
I want to enforce version control (for obvious reasons), and my choice is git (with a local Gitlab installation), which I've already set up at the company.
Here's the tough spot: The agency always needs a version of the site running during development (accessible by their client and themselves) for layout checks by the client as well as data entry (by both the client and us). Let's call it "staging", for lack of a better term.
I know this is far from a standard setup, but usually deadlines are so tight that the client (or the agency) have to start entering data as soon as any section of the site is finished. This is the way they've been (successfully) working on dozens of projects so far and I'm not the one to suggest otherwise.
The most satisfying solution I've come up with so far is the following:
Website project (as opposed to WAP), and app_code is your friend.
Common database (via VPN, a bit slow, but generally ok)
Bonobo Git server on staging server, multiple repos (two - one for
staging with Bonobo, one "official" with Gitlab).
Staging server accessible by the client (meaning the website, not the server itself)
So the scenario is that everybody will get their own copy of the site from Git (/bin folder included since it will be a website project and everybody will need any new or updated DLLs), access a common database, share the same media folder contents and only update the staging site with new pushes from time to time.
This obviously has many disadvantages, the main of which is no Web Application Project, meaning less control over things. But it can also be beneficial to the scenario described above.
Any views or ideas on alternative ways of achieving the same result?
EDIT: I've worked with said agency in the past - but I would work directly on their "staging" site (which would be a website, not a WAP, of course). I would work on my own copy (backed by version control) if needed, but their "staging" site was what was visible to them. They would change things there, all of them, accessing shared folders. This approach is, obviously, extremely wrong and cannot go on any more, so I'm looking for a better way to organize work without losing the benefits they have from this approach so far.
We use a very similar setup at the agency I work for, aside from we currently don't have any remote workers, but when we work from outside the office we connect to the shared database via VPN like you mentioned.
We have a normal IIS site setup on our dev or staging server which the client can approve/edit, which gets updated via a push to the master branch to the repo hosted on bitbucket using TeamCity. I'm not sure why you'd need two repos?
I would however strongly recommend excluding the /bin folder just as I would advise against including compiled .css/.js files, only the source files should be in a repo and the build steps should handle the rest. For dependencies not using NuGet (so aren't automatically included in the bin when building) we have a dependencies folder and a post-build task which robocopies them into the /bin folder.
Our solutions have a few projects, one of which is the .Web project containing the Umbraco installation, and others like business logic which keeps things seperated. I'm not sure why you wouldn't be able to have a web application project?
Feel free to ask any questions, hopefully there's a few ideas that might be useful.
This is a very interesting approach. I hadn't considered CI until now.
(You meant to say "recommend against including the /bin folder", right?)
Your approach essentially eliminates the need for a WSP, so yes, with this approach I could definitely use a WAP everywhere. The dependencies folder approach is very clever.
Some questions that are probably easy to derive answers for, just want to ber sure:
Yeah, sorry it was late at night! I've edited the post to not confuse others should they find the thread.
In response to your questions:-
is working on a reply...