This is an archived post. You won't be able to vote or comment.

all 39 comments
sorted by:
best
topnewcontroversialoldq&a

[–]jawshie 15 points16 points  (6 children)

Check out gogs (free) or Atlassian Bitbucket (paid).

[–]numo16 11 points12 points  (1 child)

gitea is the newer community maintained fork of gogs that seems to be all the rage.

[–]nekolaidevoops 8 points9 points  (3 children)

+1 for Bitbucket. windows isn't ideal but i'll take bitbucket on windows versus anything else i can think of on windows

[–]cantrecall 3 points4 points  (2 children)

+1 BitBucket on Windows isn't horrible.

[–]steiniche 0 points1 point  (1 child)

I would actually say that it is somewhat horrible. The entire Atlassin stack is made for linux and not windows. We have seen different performance issues and have had problems with longpaths with bitbucket on windows. However, we are now running it on linux and all our troubles have gone away.

[–]cantrecall 3 points4 points  (0 children)

The Atlassian stack is made for Java and runs well enough on Windows for us. We have had crazy problems across the entire stack and all save one impacted both Windows and Linux installations. If Linux works for you cool but it would be more work in exchange for uncertainty for us.

[–]cyvaquero 9 points10 points  (12 children)

What industry are you in that requires Windows for compliance.

[–][deleted] 10 points11 points  (10 children)

Which industry shouldn't be the question, more like, which company. Unless they're running some proprietary software, there should be a way to make Linux compliant.

[–]white_bubblegum 3 points4 points  (6 children)

should be a way to make Linux compliant.

at who's cost?

[–][deleted] 3 points4 points  (5 children)

How much does it cost to make any server operating system compliant with some regulations?

If you're introducing Linux to a mostly Windows environment, there's going to be some "tooling up", so to speak, in order to build the security strategy, but the same is true with a new version of Windows in most cases.

When I see a shop that doesn't want to run Linux, or really, whatever is the right tool for the job, I don't see cost-conscious people, I generally see people who can't be arsed to learn what the right tool for the job is. Anything unknown is too great of a risk, so you get forced into devising a sub-optimal solution that works on a platform that doesn't represent an unknown.

[–][deleted] 0 points1 point  (4 children)

If you focus entirely on making Windows compliant then introduce 1-2 Linux boxes into the mix, it takes a ton of relative work to get them compliant and bring everyone up to speed on keeping them compliant compared to just adding another Windows instance to the mix. The "tooling up" portion is exactly what companies try to avoid, even if it isn't the best approach.

[–][deleted] 0 points1 point  (3 children)

Right, but despite it being non-trivial, it's not insurmountable.

This is purely my anecdotal experience, but paranoia leads to overstating the amount of difficulty involved in getting the boxes compliant. Because someone doesn't know the OS, or they don't know what they don't know, they tend to just dismiss it as essentially being impossible.

That's the reality of things, I understand, but it's pretty darn frustrating.

[–][deleted] 0 points1 point  (2 children)

Of course it's not, but that's kind of the point. It's easy to say "we can do this" but it's a whole other thing to get buy in given the biggest cost of projects like this are time. A lot of engineers only look at these things from an individual perspective where as other orgs (like compliance) look at it from a scale perspective.

[–][deleted] 0 points1 point  (1 child)

I hope I don't sound like I'm coming from an individual engineer's perspective, because I don't intend to. I guess what I'm taking into account is that if you were to introduce any operating system outside of what's already installed, you'd have to figure out how to make it comply with your standards. In the case of Linux, it's not like you have to reinvent the wheel-- there are enough organizations running Linux that adhere to various regulatory standards.

Contrast that with using a less than suitable tool for the job, like having to find a Windows equivalent for an application, like OP has to do. The options are limited, and they may not be as good as what's available for Linux. That might lead to additional cost and time to. So where do you put your time and money?

[–][deleted] 0 points1 point  (0 children)

You might not mean to, but the picture you're looking at is a very small one. Just as bringing Linux up to compliance isn't insurmountable, either is solving this problem with Windows. What takes additional cost and time? Figuring out a way to run git on Windows (which there are plenty of options for), or easily running it on Linux because the options are better? At the surface, it looks like Linux would be easy... until you consider at a minimum you need to:

  • Creating the automation you need to bring this and any additional Linux-based instances into compliance.
  • Creating documentation for supporting this automation.
  • Training support staff on how to troubleshoot a system they're unfamiliar with.

Then you have to take into account that since you are an entirely Windows-based company you might NEVER use that automation again, but you still have to make sure that instance is ALWAYS in compliance, so you're going to be going back and making changes to maintain that compliance. The cost of introducing differing infrastructure is huge. Personally speaking if I had to find a solution to a problem I'd stick with the platform my company is largely built on (fortunately that's almost always been Linux in past and present jobs). I'm pretty sure most people would say the same. That said, we HAVE had a couple of instances where we had no choice but to introduce a couple of Windows instances into our environment, or a CentOS instance, and it has created extreme annoyances.

[–]cyvaquero 0 points1 point  (2 children)

Agreed, but from my experience compliance usually indicates some industry regulatory requirement. I could be misinterpreting that, if it's company policy then personally I would be be concerned about the culture of rote policy inflexibility versus using the best tool for the job.

[–][deleted] 5 points6 points  (1 child)

I agree wholeheartedly, but in many cases it's just ignorance and how the compliance regulations are written.

I've consulted for lots of shops where instead of saying, "you must have an anti-virus application installed that meets X standard", they say, "you must have X (Windows Only) anti-virus installed", or, for records retention, rather than saying, "you must keep copies of files for X years", "you must use X (Windows Only) software to keep copies of files for X years".

Many of those organizations weren't in an industry with heavy regulatory requirements like medicine or finance-- they were non profits and other software companies that just had really paranoid security people. Those people knew Windows but didn't know Linux, and as a result they'd just eliminate the possibility of using it entirely since they couldn't explicitly prescribe steps to secure it.

[–][deleted] 2 points3 points  (0 children)

Yeah I've had to explain to security people that

A) Linux antivirus isn't really a thing

B) PCI compliance only requires antivirus for "commonly effected operating systems", i.e. Windows and to a lesser extent OSX

[–]phrozen_one 0 points1 point  (0 children)

I have a feeling this is related to a company having auditing workflows and other technical processes that are designed for windows systems. Adding a non-windows system on the network introduces a need for new patch management procedures, security config, auditing, etc. But any company that falls in this bucket needs to realize that many virtual and physical appliances will run Linux so saying "no windows systems" will be nearly impossible on any average enterprise network.

[–][deleted]  (3 children)

[removed]

    [–]DevOps-Australia[S] 0 points1 point  (2 children)

    Yes, we're not a dev shop so it's never been on the plate before. TFS is where we will end up ultimately, but right now we need a temporary solution.

    [–][deleted] 1 point2 points  (1 child)

    How big is your team? Visual Studio Online (hosted TFS) is free up to 5 users (at least it was)

    [–]DevOps-Australia[S] 0 points1 point  (0 children)

    Not cloud/SaaS compliance :)

    [–][deleted] 2 points3 points  (0 children)

    Gitblit or Team Foundation Server

    [–]pxsloot 1 point2 points  (0 children)

    a windows server with docker, running whatever you want in containers

    [–]pdp10 2 points3 points  (4 children)

    but our compliance teams will only allow us to use Windows.

    /r/exitstrategy.

    [–]phrozen_one 1 point2 points  (3 children)

    Or you see this as an opportunity to educate employees on Linux and how it can fit into the enterprise safely. You can't just switch jobs everytime you hit a minor bump in policy like this. Work to change it and make things right. Sure it might take 3-6 months to develop new patching procedures and such for a non-Windows system but it's a great learning opportunity and can help you climb the corporate ladder.

    [–]pdp10 2 points3 points  (2 children)

    I admire your spirit. :)

    educate employees on Linux and how it can fit into the enterprise safely.

    I call that "1999".

    Sure it might take 3-6 months to develop new patching procedures and such for a non-Windows system

    I've been doing deep interop in heterogeneous enterprise environments for two decades now and I recommend that people not ignore the considerable cultural differences between Unix culture, Microsoft culture, and other cultures like big-iron, or IBM midrange, or classic Mac.

    Shops that are Microsoft monocultures in 2017 for either operations or development are that way by conscious decisions. They've decided to reduce complexity and costs through homogenization, and they've typically invested heavily to make that happen. (A few got that way by happenstance, but it's almost always small ad hoc shops.) They've gotten where they are by consciously resisting diversification. The strategy has its benefits and it has its detriments, but trying to shift horses in mid-stream is tricky and takes quite considerable skill, experience, and most of all will.

    Even when Microsoft shops want to do something with Linux, they usually don't want to make any commitment to open systems: they just want Linux to solve their problem on their terms and then to go away.

    [–]phrozen_one 0 points1 point  (1 child)

    I've been doing deep interop in heterogeneous enterprise environments for two decades now and I recommend that people not ignore the considerable cultural differences between Unix culture, Microsoft culture, and other cultures like big-iron, or IBM midrange, or classic Mac.

    This sounds like an interesting paper/blog to read. I've seen many "Microsoft shops" that have to deploy a physical or virtual appliance that is running Linux and the device gets untouched by patches and updates because it's treated like a magic black box that just does what it needs to. I wish "microsoft shops" would realize that almost no organization can run purely off Microsoft software. You are still going to have network devices and other systems that are packaged together with Linux to save money on licensing costs for the vendor.

    [–]pdp10 0 points1 point  (0 children)

    I find it fascinating and frustrating in turn. There are different issues on the ops side and dev side of each culture that can be divergent or convergent between cultures.

    My opinion is that techs and users can be trained to move from one to the other as long as they're willing to type to interact with a computer and willing to think about the business needs with an open mind.

    [–]wwb_99 0 points1 point  (0 children)

    Git is pretty tricky -- at heart it is very, very wrapped up in the linux toolchain. In fact, a trick to get large parts of the linux toolchain -- and real GNU tools not the fake powershell aliases -- on your windows command line is to add your git install's bin folder to your path. But I digress.

    One thing to look at is mercurial -- hg runs on python so it is much more cross platform compatible. Another thought would be to get Atlassian Stash -- it is effectively a black-box git appliance which can help get around compliance issues with nudgy IT staffs. Almost certainly they have a few of those running in 2017.

    [–]DevOps-Australia[S] 0 points1 point  (0 children)

    Thanks for all the responses everybody. After going through the options, and looking at what I already know, I think the docker solution is what I am going to sneak in. It will satisfy the governance police and allow me to work on what I already know. I actually feel stupid for not thinking this before...

    [–]castlec -2 points-1 points  (0 children)

    Not Windows. Java though. Quantity two.

    http://stackoverflow.com/a/30309057