How Azure scaled to 2,000 employees on GitHub
azure.microsoft.com
azure.microsoft.com
It's even worse for agencies and contractors, since for them changing projects often is a natural part of business.
Hosting a git repo and a very very basic issue tracker is so not worth $2500/year. Not to mention that even this isn't a fixed price and it grows linearly with the number of employees.
GitLab provides the same service for free. Well, at the cost of "you reading the manual and installing it on a VPS", which takes between "minutes" and "a couple of days" depending on how deep you want to go. A VPS that can easily - easily - scale to the needs of 100 people is "$5/mo".
Looking cool and having brand recognition will indeed earn you money, but everything has its limits.
... And managing and maintaining that server and backups of it. $2500 a year starts to look pretty reasonable when you consider the amount it will cost you to put one of your developers on to setting it up and maintaining it. Not to mention the peace of mind of not having to worry about disaster recovery.
I don't worry about backing up the git repos, one of the promises of git is that every person who checks out the repo has a full copy, any of which we could use for a backup (helpful if we get a recent checkout).
Third party hosting hopefully has a good disaster recovery plan, but the disaster could be your hosting provider quietly went out of business and everything is offline.
It's $250/year per developer, which is a rounding error at most software companies.
The same is true if you host yourself. Storage is neither free nor infinite. Sure you could scale your storage, but that costs, too. Unless you're absolutely strapped for cash, I think this just encourages good hygiene.
I've done precisely that for personal projects in the past, as well as for a couple small teams as an intermediate step towards hosted git. I support GH mainly because they are supporting open-source... it's indirect, but I support the model.
Frankly, there are hard problems in internal IT, but hosting a bunch of git repositories is a non-issue.
Yet all of this comes to less than a gigabyte, which is well under the limits of the free tiers at most major storage providers.
In terms of storage costs, Github for most projects is several orders of magnitude more expensive than other storage providers even if you ignore the free tiers.
As someone at Google once said, "If your policy doesn't exist in software, it doesn't exist."
I do not want my repositories to be all in a linear list, with my various chess projects, my various math projects, my various game projects, and so on all mixed up. And I do not want to resort to kludges like prefixing projects with chess- or math- or whatever as an inadequate workaround.
It's not much better than prefixing, but it really isn't so bad... What gets me is the leftover cruft when I fork to make a patch to an upstream project.
You mix in larger number of developers, add in QA, testing, release, issue tracking states between them and it becomes a pain. Having to implements bots, API keys other stuff like that.
Not all tools work for everyone. What works for individuals and small teams doesn't work for larger teams.
I saw this twice both at a smaller company and larger one. Starting with Github. Hit pain points and then picking something else. In one case was about buying Jira + Confluence, because it was about issue tracking states. In another not sure yet. But lots of bots and rules and automatic pull requests and merges is becoming a pain and might end up with Gitlab or something else soon.
I wish the Visual Studio Online team would look a little harder at Github and steal more of its Issues experience, and have something more lightweight than the backlog monster they've got now. I think it's not uncommon for VSO users to keep a Github sync of their code so they can use GH for issues and day to day code and VSO for builds and deploys.
https://www.visualstudio.com/en-us/products/visual-studio-te...
Wouldn't "TFS Online" be a better description if you want to stock with the Microsoft unimaginative naming policy? At least it says exactly what it is.
My personal opinion is that Microsoft should just go with the internal names. They are more interesting and memorable for customers. They are often one word, rather than five. Visual Studio Team System Online 2020 Developer Edition.... Sorry, started snoring after 3 words.
At least the way they do it now gives some control to the org as to who has access to their account. It's inconvenient but it biases towards making on boarding hard to make control and off boarding easier.
Also, GitHub wants to avoid the same person having multiple accounts. Their focus is the developer, not the org. So they want all your work to be associated with you.
I still have stuff on my account that is associated with Netflix and reddit. Because the account is tied to my personal account, those orgs can never "remove" my contribution.
This portal is really nice compared to the previous system, which was send an email to someone and wait for them to get to it. :)
Previously you could only add a user to your org by knowing their GH username. I was always paranoid I was going to typo and release my code to some random user.
For a while we hacked around this problem by letting third party associates "invite themselves" using a one-time use token in our portal, but we moved away from that since we no longer join externals to the org.
We're thinking of bringing it back, though, for "Outside Collaborators".
I work in DX/Evangelism at MSFT and a lot of work around containers, etc, at the moment is easier on *nix than it is on Windows (for me). I've got both machines as well as a Windows VM on the Mac if I need something there...
Which would be Chrome then (since it dominates browser share), instead of Safari.
Perhaps the person making the screenshots wanted to use a *nix system, but didn't want to be caught showing off the competition's product.
Personally I use Safari when I'm on battery all day (coffee shops, etc.), Chrome when I need multiple profile support, and I tend to split Chrome/Edge when in my Windows VM.
I do sorely miss using a Mac (first time after nearly 10 years that I don't have one at hand, and it's a drag on productivity for me when I need to talk to Linux servers or run some tools locally), but I don't think anyone would blink twice if I brought my own Mac to the office, even considering that I'm at an European subsidiary.
I think I remember about ten years ago somebody got fired from Microsoft for posting a photo of a MacPro (or two) being unloaded on the Microsoft campus. (Even though Microsoft was, of course, developing Office for Mac back then, so it was kind of obvious there had to be a couple of Macs around...)
My memory might be playing tricks on me here, but if it's not, things must have changed quite a bit.
It's a scary place to be in when we're 1) dependent on a third party, 2) we have to follow GitHub and the API down the rabbit whole, and 3) we are just trying to enable our team to get going fast and hope in time GitHub can just give us all the right tools that check at least some boxes we need, i.e. very granular management to delegate decision making even more.
Any data that is stored on GitHub (ex issues, PRs) can be pulled down via the REST API. So, it should be relatively easy to build a migration tool or alternate UI if necessary.
These days:
- JIRA - for internal, complex project management because the plugins are really good
- Confluence - wiki w/ plugins
- Asana
- Slack/FlowDock - waay better than digging through HipChat/Campfire, IRC
- Hubot - integrations/CLI for everything
- jenkins - for private CI
- Github enterprise - or maybe Gitlab if one can get away with it
- Google Apps for Work / Zoho - because of AD integrations
PS: When deploying a portal page whether internally or for a client, a bespoke 404 page with either a game or random funny images is the way to go. Maybe a humans.txt too.
Sadly, wish I was joking. But it happens all too often.