3

I am rather new in my workplace (some months).
I am having trouble convincing my boss not to make a big mistake for which the company and the software team is going to pay.

As for today, we are (still!) working with TFS.

Finally, a decision was made to start working with git.

Ever since the company was founded, they had the following workflow:

  1. Write some c# code
  2. Run an over-night build
  3. Automatically check-in .dlls to TFS source control.

When working with TFS, this is bad, but doesn't hurt as much as it will with git, because cloning will soon become very painful.

I want to prevent this before it happens.

How can I get my boss to discourage pushing generated files to source control?

My bosses reasoning is:

  1. This is the current culture, when people go overseas they want to be able to quickly get-latest and have the running code ready
  2. Some compilers we use are licensed, and not all of the team have licenses, so it would make it difficult to collaborate.
  3. Making this process automatic is not intuitive to any of us, and doing what we have always done would allow us to go on with the work plan.

I wonder if I should insist. If I should, how can I approach him?

The final decision will not be mine, but at least I will know I did my best.

  • Is the original code also in the git, or only the .dlls? Maybe come up with a plan that mitigates the problems. Like 2 separate gits, separate binary branch, ci system which stores the 10 (or 20 or 100) builds. Or if it's really only about latest: only have the latest on a fileserver? – Benjamin Jul 17 at 11:04
  • Would doing a nightly build based on the code in source control be an acceptable solution? – Ruther Rendommeleigh Jul 17 at 11:06
  • 1
    Hi Gulzar, we can help you with the workplace aspects of how to approach your boss, and I've edited your question to better reflect that. If you are specifically looking for technical arguments, then this question should be moved to a different stack. Which are you looking for? – David K Jul 17 at 12:20
  • 1
    I'm voting to close this question as off-topic because it belongs elsewhere. – Gregory Currie Jul 17 at 12:55
  • 1
    @Gregory Currie I think the answers contain useful information separate from the technical issues. If you'd like to re-write the question in more general terms to bring it more into line of what you see as "on topic", feel free. – jsarbour Jul 17 at 13:10
13

A general rule is: Don't go to your boss with problems, go to him or her with solutions. [1]

Saying "this is a bad idea, if we do it we'll be sorry in a year" isn't helpful.

What you need to do is to come up with an alternative plan that avoids the problem while also accomplishing the goals of the problematic one.

In your case I assume it would be some form of CI that stores build snapshots somewhere else that's easy to access; but what to use and how to configure it are really a question for a different SE site.

1) This isn't an absolute, there will occasionally be times you can't come up with a solution even after thinking about a problem for a while and brainstorming with your peers. But you're more likely to accomplish your goals when you present solutions to issues your boss may not have even been aware of, and don't want to acquire a reputation as a chicken little who has unproductive freakouts over every little thing.

  • I really like the answer and suggestion. With limited number of license for compiler, CI is exactly something they need to be looking for. However, the boss "may" refrain from this idea on the ground of "spending more money" to get a tool that they "don't even need". – Nimesh Neema Jul 17 at 11:09
  • 2
    @NimeshNeema there're things you can do without a CI server (eg having an upload the binaries step in your build scripts); but the reference to nightly builds in the question strongly implies that a CI server of some sort is currently operational. – Dan Neely Jul 17 at 11:13
  • 1
    While having a better solution is the correct way to move forward, the OP still has to be able to state (in non-subjective terms) why the current solution is problematic - otherwise the boss may think the OP wants to change things just for the sake of changing them. – Peter M Jul 17 at 12:31
  • This, the answer is don't argue with your boss only bring him solutions – user86742 Jul 17 at 15:23
  • I agree with this answer, which is why before it got edited I asked for solutions as well. I am not a DevOps guy, and don't really know the solution for my particular problem. I do know enough to know the current way will lead to bad things, and that better ways exist. I really only wanted him to stop and think before running onwards. – Gulzar Jul 17 at 15:44
1

Right now, you are arguing with your boss about abstracts. About the future, which is hard to predict. Convincing someone your prediction of the future is going to come true has been a challenge for millennia :)

It's easier to argue based on facts. So if you think there is something in the future that will go wrong, simulate it. I assume you are a programmer, so it should not be hard.

If you think 3 years down the road, after let's say 10.000 commits and pushes, cloning will be hard, then take an empty repository, simulate those three years with a script that just commits and pushes 10.000 little changes and then clone it. Benchmark it.

Then use those numbers and approach your boss. Be sure to stay factual and make sure you have an alternative. "Don't do this" is not an alternative. Figure out a way to not do it, but still work with all the scenarios described. I cannot tell you what it will be. Maybe a company-wide nuget server? A file-share? An extra repository for binaries only? Your choice. Pick an alternative and show it's better based on facts.

If your boss, after seeing facts, still wants his solution, that is the point where your job is done. That is a business decision that your boss is there to make. It might seem like a bad one to you now, but if that is what your boss wants, that is what your boss should get.

0

How to convince my boss not to commit binary files and assets to git?

I feel you have already done your part. Further convincing or pushing him with more arguments isn't going to automatically change the situation.

I wonder if I should insist. If I should, what would be good technical arguments?

Refrain from insisting anymore at this point. Maybe there really are limitations (such as limited licenses for compilers) which this workflow may hinder. And the team/boss is not aware of a better workflow yet. (I'm with you about not committing binaries in Git repository).

If a situation arrives in future, which will let the boss and the team in general see the value of your argument, change will happen for good. Sometimes you may not be in a position to dictate changes, howsoever good they may be.

I am rather new in my workplace (some months).

Don't forget this. Nothing wrong with you or your boss, but wait till you have earned the trust by spending time and by demonstrating your work, expertise and understanding of git.


There's a common theme in workplaces to not fix something that isn't broken yet. Sometimes you couldn't help but wait for things to break or earn the trust where you can dictate changes.

  • This is the correct answer. You’ve done your bit, if he doesn’t listen it’s not your problem. – gnasher729 Jul 17 at 15:11
-1

I think, like has been mentioned, going back with a solution is always better than pointing out problems.

In this case Git is great for source code management, however you may want to use it for something which it was not really designed for. Maybe you can use something like Artifactory (or something similar) as this is for the result of your build process, not the code itself?

-2

I don't think it's particularly wrong in this case to check in some dlls, specifically the ones generated from licensed compilers. And I don't see where is the big mistake that the company will be paying for.

Having said that you should propose to follow best practices, instead of pointing fingers at them being "wrong", because they are not. For example, any dlls being generated by 3rd party compiler should be saved in some sort of library or dependency folder from where they'll be referenced. For dlls from the codebase, make an argument that it does not serve any real purpose. If the concern is to have a running version in the repo, then create a proper build/installer file and store it at some storage, usually part of the CI process. Anyone having access to codebase does not need the dlls. Add a .gitignore file, show them how smaller the repo becomes without the unnecessary files, make sure you add those library dlls in the .gitignore file, you don't want to break it.

Finally, it's not the end of the world, don't be too dramatic. It's not such a huge mistake as you think it is.

-4

Nothing wrong with committing binary files. The versioning system is there for you to commit anything reasonable for the project. Compiled binary files on versioning for a private team is more than reasonable.

There's no need to convince your boss for something that's working. Your boss made the right decision.

  • 4
    From a technical point of view, this is awful. These guys will feel pain in 6 months, serious hurt in a year, and things will be unbearable not much later. – gnasher729 Jul 17 at 15:10
  • 1
    expanding on @gnasher729 's comment slightly. The reason this is a really bad idea in git (but not nearly as disruptive in some other source control systems) is that in git your local repo has a copy of everything ever committed into it (vs only having the most recent version and require server IO for historical versions) is that the binary files will result in the repo size growing very fast filling up large amounts of disk space and slowing down operations that require hashing the current state of every file. – Dan Neely Jul 17 at 15:30
  • @DanNeely, Unless you use .gitignore, in which case this becomes a non-issue. – Stephan Branczyk Jul 17 at 15:41
  • @StephanBranczyk I thought .gitignore only hid files from being seen as new/changed but didn't affect what was pulled from the repo, while the problem here is the boss wanting to put daily build binaries in the repo. Is there a don't-bring-these-files-from-remote component to .gitignore I'm unaware of, or did you mis-understand what I was saying? – Dan Neely Jul 17 at 16:05
  • 2
    One additional technical note is that, while it's absolutely correct that including build artifacts in the repo itself is a terrible idea, most cloud-hosting platforms for git also have a way of storing build artifacts (typically, release builds) and documentation, separate from the distributed version control repo for the source. Having a way to distribute build artifacts is a legitimate concern, but it's very important when using distributed version control to handle these artifacts separate from the repo itself. – Dan Bryant Jul 17 at 17:05

protected by Community Jul 17 at 15:14

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.