|
Exactly what happened.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
|
We're thinking of moving our development environment over to VSTS, but we don't know much about it or how it works.
We are small team of 3 developers and each have a local install of Visual Studio 2017 Professional on our work PCs. We use an on-premise Team Foundation Services 2015 for all our builds and releases.
How does VSTS work? How do we develop, build and release our software using VSTS? For those that are using it, what are your thoughts?
"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
|
|
|
|
|
We used VSTS/Git at my previous company. Was a smooth experience. Especially if you deploy to Azure.
|
|
|
|
|
We use it actively and are very happy with it. Its Git integration is superb, issue management is top notch (as you know it from TFS 2015) and the CI/CD capabilities are outstanding. Best thing is the Azure integration.
We also heavily use the dashboards, test management, private package feeds, and the team collaboration tools (e.g., calendar).
All in all you get the product you know already / love (TFS 2015+) in a (even) more modern design and always up-to-date mode incl. even better Azure / cloud integration. On the downside you may have downtimes / unexpected behavior from time to time (e.g., our Azure deployments sometimes "fail" out of no reason, VSTS makes some unstable updates, useful features are removed / redesigned).
|
|
|
|
|
I moved from Jenkins to VSTS last year and I was amazed at how easy and intuitive VSTS is.
Integration with Git and Azure is amazing, ticketing and scrum is smooth, I'm never moving back to Jenkins!
You can set up an entire CI/CD environment from VSTS to Azure with a single button click (in Azure)! 
I worked with TFS a few years ago and it was horrible, not anything near the beauty that is VSTS today (alright, "beauty" is a slight exaggeration, VSTS still has some rough edges).
I can recommend getting an @outlook.com account (if you haven't already) and check out VSTS yourself.
You can create a free account with your outlook account and invite other outlook users.
The free account even offers free private Git repositories and builds and releases 
|
|
|
|
|
We have ASP.NET Core and Web API projects under TFS which I would like to migrate over to VSTS. Is this possible? Where can I find documentation on setting up CI / CD with VSTS?
"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
|
|
|
|
|
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
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
