|
Nope
98.4% of statistics are made up on the spot.
|
|
|
|
|
Hepcat?
Sent from my Amstrad PC 1640
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Nope
98.4% of statistics are made up on the spot.
|
|
|
|
|
From the second clue:
Business information BI
store SHOP
for clerical worker
BISHOP
And that leads to Walter Bishop Jr.[^] who played jazz piano.
Sent from my Amstrad PC 1640
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
We have a winner!
The fist clue was ISH = "sort of" getting into jazz = "BOP" leading to a (chess) man.
It was my wondering whether "man" for chess piece is ever used outside of the UK ...
I'm not familiar with Walter Bishop - must check him out. I suspect that my old man has a pile of his records somewhere.
Whenever you find yourself on the side of the majority, it is time to pause and reflect. - Mark Twain
|
|
|
|
|
https://paleofuture.gizmodo.com/what-international-air-travel-was-like-in-the-1930s-1471258414
|
|
|
|
|
404 - Post Not Found: 147125841
No idea what you wanted to show us, but this is the way I air travelled in the late 1980s:
https://eatc-mil.com/uploads/news/Transall%20over%20Goose%20Bay.jpg?v=30
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.
|
|
|
|
|
I can access it...
|
|
|
|
|
|
I accidentally cut off the last digit of the post's number when I copied the link. Now it works. Very nice way to spend some time in the air. No comparison to the Y-Tours flights I used to have.
(https://eatc-mil.com/uploads/news/Transall%20over%20Goose%20Bay.jpg?v=30 but I never went to Goose Bay with Y-Tours)
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.
|
|
|
|
|
maybe you missed the last '4'
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
