My company is currently implementing a versioning system using Mercurial and BitBucket. We currently have respositories set up on bitbucket and are able to use them, but our work processes for doing so are a bit clunky. We use Visual Studio for web programming in .Net. Currently, we have set up a cloned repository locally and work from there. We can do this using Visual Studio with VisualHg.
In order to edit files we open them in Visual Studio from the local repository and make our edits. We then commit our changes to Hg, which updates the repository as it should. Then we need to FTP the files from our local system to the DEV server for testing and then FTP again to the Production server once QA is completed and approved.
It would help streamline things if we could have the BitBucket repository synced with our DEV server so that all that was required is to commit changes for testing in DEV, bypassing the otherwise necessary step of locating and FTP'ing all relevant files.
Does anyone know if this is possible? If so, can you point me to any documentation that would show me how to set this up? Our developers would be eternally grateful. Thanks for your time.
In my opinion, using Mercurial is not the correct solution for this problem.
The main reason for it not being the correct solution is that the files that are in Mercurial are not the files that you want on the production server and so aren't the files that you want to use on your development server (because you want the QA environment to be as close to the production environment as possible). There are no assembly files stored in Mercurial (or there shouldn't be) and those are the files that the server should be using to run the application.
There are deployment tools built into Visual Studio that you can use for this task. They can be configured to upload all the necessary files with one button click.
Scott Hanselman has a post on his blog about this.
Troy Hunt takes it one step further by introducing a build server with this excellent set of posts. It uses Subversion as the repository but it can be done using Mercurial too.
I prefer the build server method as, once you have it set up correctly, it makes it 100% reliable. It will do the same thing every time you ask it to do the deployment. If you use Visual Studio to do it the developer doing the publish could choose different options and get it wrong.
Related
Me - Front End web developer with an ok working knowledge of writing VB.NET code but I have never built a .NET project from scratch using Visual Studio.
External developer - Experienced VB.NET developer but completely new to version control and TFS. Also extremely cheap and prone to infuriatingly poor programming practices. He does things that make you bang your head on the table.
Background
Our external developer has coded our site but over the last few years I have been tweaking aspects of pages and have managed to learn quite a bit of VB.NET along the way. He has never used source control and I don't think he's ever had to work with another developer before.
Up until now he has maintained a local copy of the website. He makes changes to this local copy and when he wants us to test it he uploads the relevant files to our dev server. I have no experience of Visual Studio projects/solutions so if I have made tweaks to things I have edited the aspx/asxh/config files in my preferred editor and then uploaded them to the dev server. If everything works correctly I ask him to download them from the server so he can update his local copy.
I have been maintaining a local git repository of the website for the last 2 years. If he makes a change I check it in.
Obviously this is a nightmare to work with so we have now insisted that he starts using version control. I recommended GIT but he has decided to use TFS.
He has now put his solution and all the files into TFS. I have installed Visual Studio 2015 and successfully connected to TFS. I have mapped the files from source control to my own workspace but I am now at a loss as to what to do next.
Questions
As soon as I open the .sln file he has uploaded it says I have checked out the file and made changes. When I check the diff it seems to be because I am using a newer version of Visual Studio than he is. Does the .sln file need to be in version control? Or are we suppose to maintain our own versions of the .sln file and simply check in everything else?
If I try and build the project it fails because the web.config is set up for his machine and not mine. How can we maintain 3 versions of the web.config file? One for my local, one for his, and one for our dev/live environments?
I am not convinced he will have added the project to TFS correctly because he's never used it before. This is basically the blind leading the blind.
Question 1:
You need to put the .sln file in version control. Before check out the .sln file, please do a "get latest" step, which will make sure both of you are working on the latest version. When you try to check your local version in the server, and he had uploaded his local version in the server. You may have to solve conflicts before the check in.
Question 2:
You should build your project and published the website on the server. The build agent will only maintain one version of the web.config file. If he has built the project with his web.config. And you want to build the project again with your web.config, the build agent will delete the previous web.config and pull down your version. Then build the project with your's web.config.
Moreover, if both of you are not similar with TFS. Suggest you taking a look at below MSDN link which related to source control and build.
Use Team Foundation Version Control
TFS Vnext Build
I work from a small IT department and I'm pushing to move from our current TFS implementation to Visual Studio Online. My boss who gets the final say is hesitant because "What if Microsoft decides to stop offering the service, without notice, or their servers fail how will we get our code". While I find such a scenario unlikely and the scenario of our TFS server crashing and burning with no backups/bad backups much more likely. I still need to address his concern.
Does anyone know of a way to "backup" a remote TFS implementation? So far the only thing I've come up with is doing a nightly pull of Visual Studio Online and submitting it to a local repo, feels hacky, feels wrong.
Take a look over at the discussion on this StackOverflow question: Is There A Way To Backup Visual Studio Team Services Projects?
Here is Richard's answer:
There's no out of the box backup ability.
Now, if you are only referring to source control, and not work items,
pull requests, builds, test plans or anything else that the service
offers, then I'd suggest you migrate your code over to git.
With git every developer will have a complete copy of the source
repository, including all history and commit comments. From there,
it's a simple task to push the git repository to a different git
hoster (such as bitbucket or github) and make them your new centrally
hosted git repository.
On a historical note, Visual Studio Online at one point offered a data
export for a period of time. You might want to add a vote or three to
this related UserVoice idea to help raise the importance of the
feature with Microsoft.
Side comment: The business risks in using Visual Studio Online will
come from either Microsoft shutting down the Visual Studio Online
service or that the underlying Azure infrastructure has such a
catastrophic failure that your Visual Studio Online account is
unrecoverable. Both of those are extremely low risk, and very likely
lower than the risks you'd have running TFS on-premises, in your own
data centre, unless of course, your infrastructure and staff are
better than Microsoft's :-)
I agree with Richard. Visual Studio Online is not going anywhere :) You can also use tools like OpsHub, TaskTop, and Kovair to setup a two-way synchronization or use the TFS Integration Platform to do the same thing if you really wanted an option. If you are using Git repositories, you can clone the repository into other locations to maintain multiple copies. All of those options take effort.
I posted the same answer to this stackoverflow question.
We developed our own VSO backup tool. We scheduled it as a scheduled task and it runs once a night. It then
just clones all our repositories to disk.
Taken from this blog:
We use the VSO Rest API to query our VSO account and get all the data
we need. Since in VSO you can only have one Team Project Collection,
we retrieve all the team projects of the default collection. Each of
these team projects can have multiple repositories that need to be
backed up. A folder is created for each team project and saved to a
location on disk that can be configured in the app.config. When the
team project folder is created, the task loops over each repository in
the team project and creates folders for each repository.
You can also fork it on GitHub here
I'm totaly newbie to Source Control idea, so please be kind.
My situation is that we are a development team which contains 2 developers and 1 designer.
We use Visual Studio 2010 and we need to use a Git as a Source Control.
I've installed Git Source Control Provider and GitExtensions using Extensions Manager on all machines.
But there is only one thing I don't get it, how can I configure every Git on every machine to find a central repositry where we can Push and Update all work in one place?
Does that mean everyone will take a copy of a solution into his own machine (Locally) and configure Git to a repositry OR are we going to run on the same solution?
Honestly, I have not found articles regarding this issue and how teams on same project on Visual Studio 2010?
Git is distributed version control system means that whenever you clone a repository you can work on your copy and commit too. Once you done you can push the commits to remote repository.
In our environment we are serving a combination of asp and asp.net pages on Windows 2003 servers running IIS. We use Visual Studio to edit the pages via FrontPage extentions.
We really enjoy the ability to make quick edits and save and the web is updated immediately. Don't worry, we do have a development server where we test all of our changes before moving them to the production server.
We do not want to use the "publish site" option if at all possible.
I have been using GIT for some android (eclipse) projects lately and I'm really enjoying it, so now I would like to use GIT for our web site as well if at all possible.
I've have GitExtentions installed, along with the VS plugin and I have tried Git Source Control Provider.
Keeping with the distributed VC mindset, I'd like to have a repo on my (and each of the developers) PC and commit as necessary.
The problem is, since we are editing via http/frontpage (master mode) the files are not stored locally.
I am wondering if anyone else in this type of environment has implemented a successful GIT workflow.
Thank you,
My solution isn't necessarily ideal for your situation, given you dont want the extra step of publishing...
I have the files locally in my git repo, and then I manually (via script) push them to the web location.
So I traded the ease of editing deployed files, for the awesomeness that is GIT. For me, I came out like a bandit in that trade.
Our dev team is small (3 developers) and windows based.
I'm looking for a source control that can do the following:
Check out files for editing and warn others that file is used
Check in files and merge if they have changed
Split baselines for release versions and merge baselines if needed
Visual Studio integration
Can work over WAN
Thanks.
SW
Team Foundation Server fits all of those.
SVN would be great, as long as you use locking (normally the server has no idea what clients are doing by default)
Perforce might be a nice one to look at which does this more by default.
Both have VS integration, SVN especially.
SVN, provided that you explicitly lock the files. This is not by default, but you can easily lock the file via SVN commands or via TortoiseSVN.
VisualSVN provides the Visual Studio integration.
If you want good Visual Studio Integration, then check out Microsoft Team System. You didn't specify if you wanted free or commercial or how critical Visual Studio intergration was.
git will do almost all of it. Not sure about integrating it with Visual Studio though. there might be a plugin for that.
Reasons:
No central server needed. If you want one, you can have one, but it's not necessary
You can push/pull changes to the others at will.
Each of you can have your own local branches, and push only the ones you need to
each other. Branching/merging is easy enough to do branch-per-task. Then push just that task to a co-worker if needed.
Unlike SVN, only one directory is needed for git, in the top level of the directory structure.
git stash rocks for when you have changes in your current branch, and need to switch to another for a while. This is one of those things you don't miss until you don't have.
Merges are awesome.