|
Hey,
migrating a TFS database to VSTS has some ceremony but it works, see Migrate to Visual Studio Team Services[^]. However, you have to upgrade to the latest TFS before doing so. We have done this procedure for a moderate database of 50GB that contained ~10 projects among which was an ASP.NET+WebAPI project, but the contents of the database are of no significance. However, I would suggest that you create fresh projects using git (if you are not using it already) and keep the old ones for archival purposes. Our team was of your size when this operation was carried out ![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif) .
Setting up a CI/CD pipeline is very easy, see Create your first build and release | Microsoft Docs[^] and dotNET Core|Microsoft Docs[^]. For build, we use some hosted agents for small projects and one private agent on a VM for larger native projects. In our case, we had to migrate our xaml based build definitions to the new logic, but this was for the best  .
|
|
|
|
|
Thanks for the reply and all the helpful links. I'm going to have a read through those 
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
I see your questions have already been answered 
I'd like to add that if you're using TFSSC (is that what the TFS source control is called?) it may not be a good idea to migrate your repositories to Git.
The reason is that TFSSC works completely different than Git.
The main difference that makes migrating a bad idea is that with TFSSC you can check out parts of a repository.
In my experience this means you can have a single repository for ALL your projects.
In Git, however, you check out everything or nothing, and checking out ALL your projects all the time is not a good idea.
So if this is the situation you're in you might want to rethink how many repositories you want to use.
Personally, I go for one VS solution in a single repository.
If you're using Azure App Services you want to check out the Deployment Center: Continuous deployment to Azure App Service | Microsoft Docs[^]
This sets up CD with a single button click after which you can tweak it in VSTS yourself
|
|
|
|
|
We use the default TFS source-control for our TFS projects, although we do use Git for some of our other projects (our mobile app projects are hosted under Git). So we do have some kowledge and experience of Git, altough not from a VSTS perspective.
We use Azure app services for hosting all of our applications, so it would be great to simplify this part of the process too
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
Highly recommend it.
Simply put, VSTS is the place to manage your projects in terms of work-items, code versioning, code reviews, automated builds, test results, packaging and/or deployment.
It comes with it's own (cloud-based) TFVC and git and works best with one of those. Preferably git, which is the superior of the two for smaller teams.
TFS is best for legally-bound on-premise-only projects and for legacy teams that are very big.
As Microsoft puts it:
Quote: Git is the default version control provider for new projects. You should use Git for version control in your projects unless you have a specific need for centralized version control features in TFVC.
It's free for up to 5 people. As in beer.
So is VS Community, btw, which kinda makes me wonder why you have VS Pro instead. Intentionally driving up costs, maybe?
An ideal setup for small teams is 2-5 developers with VS community, a Kanban board for task management in VSTS, git for versioning and VSTS configured for automated builds / tests on an on-premise machine (= a local agent).
You can set it up so that each time a build (+ all tests) succeed on development, you push to your master branch, build your release product, and deploy to a machine for manual verification.
It's scales very well. You can add nugget feeds, automated packaging, 3th party tool integration, custom build steps, custom release steps.. the works.
The best thing is, it doesn't cost anything and the tooling is better than most commercial available solutions.
It's not perfect though: VSTS is still changing, so you need to be able to tolerate a new layout once in a while.
|
|
|
|
|
We do use Git for some of our other (mobile app) projects, so we have experience of using Git. This should make the transition over to VSTS a bit easier.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
Our organisation uses an in-house TFS server which I originally set up, but it's still running TFS2012 as it always seemed a hassle to upgrade, along with the potential disruption. In recent weeks I've been trialling VSTS, and have now made the decision to move over to it. I've been really impressed with it, although this may partly have something to do with comparing it to such an old version of TFS.
On our in-house TFS I customised the build processes to perform additional steps such as changing version numbers in AssemblyInfo files before building, running StyleCop, generating setup.exe installers, etc. This sort of thing was a real black art, and not something I ever want to see again, but in VSTS things like this are trivially easy using build tasks.
We also have an in-house NuGet repo, but it's a manual process to generate packages from a build (I ended up writing an app to automate some of this). Again this is trivial in VSTS, both to generate a package and to host it.
The only issue I found with VSTS was the relatively small amount of free "build time" you get per month (240 mins I think). We utilise CI builds so would end up hitting this limit in no time at all so the plan is to upgrade to a CI/CD (hosted) pipeline that provides unlimited build time (£20/month I think).
Unfortunately, being on such an old version of TFS we can't migrate to VSTS, so we'll end up adding all the solutions in from scratch, losing the earlier history. We'll probably end up keeping the in-house server as an "archive" for this purpose.
|
|
|
|
|
Your scenario sounds similar to our own. I have setup several builds and releases using our on-premise TFS 2015 server including an on-premise nuget server which we use for consuming the output of one build as the input to another build. We'll probably have to re-create the builds from scratch on VSTS but that isn't too onerous a task.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
I recently started an amazing position where we are using VSTS. I say it's amazing because they really just want to reboot their whole enterprise application effort and they told me that they want Microsoft and the cloud.
So we are using VSTS, Azure, Azure Active Directory .NET Core, EF Core, Web API, SQL Server and React (?). Yes, MS is supporting Angular and React in .NET Core projects but they use TypeScript.
We are a small group and are leveraging VSTS as much as possible at this time: task and SW bug management, Git-based source control, builds and deployments to Azure. Like someone else here said, VSTS works very well with Azure. VSTS allows you to link source control branches with tasks and bugs. We still use an issue management system for tracking issues the the whole company so we can track non sw bugs (like pencil sharpener is full !!) but for sw bugs we keep them in VSTS.
If you're going to use VSTS, I recommend that you use Git. In fact, if you code anything, I recommend that you use Git. I will leave that there and if you want more info, let me know.
Another great benefit of VSTS is that being SaaS, it doesn't require VPN. I love not having to connect to VPN nor bringing my laptop home to do something. I just log onto VSTS/Azure on a different computer and I'm on my way. And we are using Azure Active Directory, so we SSO w/ our Active directory account, and we're in, and we are using that for our new enterprise apps. Again, allowing users to log on from anywhere w/o VPN and w/ any OS because everything we are writing now is SaaS.
|
|
|
|
|
The ability to work seamlessly from home is one I had completely forgotten about and would be a huge benefit. We do sometimes work from home over a VPN which is a pain the a** so this is would be a massive plus
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
Our 3 man group is slowly moving away from VSTS to Bitbucket. They both have good integration with VS2017 (VSTS a little better of course).
The main reason was integration with AWS for one of our devs. The rest of our stuff is windows desktop/service and embedded device code, so it didn't matter to us one way or the other what repository was used, as long as it was all in one location.
Since I'm part of the embedded/ desktop side, I still compile locally and deploy manually (this is custom software per machine  ) so I'm sorry I haven't had a need to figure out how build and release on the cloud
|
|
|
|
|
In Jamaica, a slice of apple pie is 427.56 Jamaican Dollars. In the Bahamas, it will cost you US$2.64. These are the Pie Rates of the Caribbean.
Sent from my Amstrad PC 1640
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Yo Ho, Ho, a bottle o rum might be involved...
|
|
|
|
|
Nope, that's gone!
In Word you can only store 2 bytes. That is why I use Writer.
|
|
|
|
|
|
|
|
No. A pi rate is $3.14. 
... such stuff as dreams are made on
|
|
|
|
|
Although you post these knightly you probably shouldn't depp your toes in these waters. Pie Rates can be very dangerous and Pi Rates are always irrational.
I'm pretty sure I would not like to live in a world in which I would never be offended.
I am absolutely certain I don't want to live in a world in which you would never be offended.
Freedom doesn't mean the absence of things you don't like.
Dave
|
|
|
|
|
I say
I don't like cricket, oh no
I love it
I don't like cricket, no no
I love it
sorry, first thing that popped into my head
... and now you can be stuck with it too
This internet thing is amazing! Letting people use it: worst idea ever!
|
|
|
|
|
It's still highway robbery, no matter how you slice it.
|
|
|
|
|
|
No don't worry this is not Soapbox stuff, it is not about those Americans...
It's about The Americans, the TV show. It takes place in the last decade of the Cold War, where a couple of Russian spies are embedded into US society as a bunch "regular guys". Last nights episode was called "Do mail robots dream of electric sheep?". You gotta love references like that. I find the series quite enjoyable, have you watched it?
... such stuff as electric sheep are made on
|
|
|
|
|
|
I would not call it plagiarism. It is a rather obvious reference [to the novel].
... such stuff as dreams are made on
modified 3-Jul-18 8:37am.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
