|
I'm curious how versioning is managed in a monorepo. For our microservices we have our build process push tags back to the repo so we know what code was used in what release. I can see that pattern working fine if every build from the monorepo creates a release but if I have 5 different services hosted from the same monorepo and I don't want to release them all at once, I'm not sure how you can maintain that release == git tag/sha mapping at the repo level.
|
#
?
Jan 5, 2019 13:45
|
|
|
|
| # ? Apr 26, 2024 04:23 |
|
|
Blinkz0rz posted:I'm curious how versioning is managed in a monorepo. I don't entirely understand what you are asking but product teams control their own builds/releases. A build is created based on a CL (changelist, essentially a snapshot in time of the monorepo) and deployed. If you've got 5 different services then there will be 5 different setups for the build/deploy process and you can deploy them at different CLs. If your service is directly pulling in a dependency (#include rather than making an RPC to the service) then you get whatever changes were made prior to the CL you're using. That causes occasional problems, but for the most part it works fine
|
|
#
?
Jan 5, 2019 15:24
|
|
|
Jose Valasquez posted:I don't entirely understand what you are asking but product teams control their own builds/releases. A build is created based on a CL (changelist, essentially a snapshot in time of the monorepo) and deployed. If you've got 5 different services then there will be 5 different setups for the build/deploy process and you can deploy them at different CLs. If your service is directly pulling in a dependency (#include rather than making an RPC to the service) then you get whatever changes were made prior to the CL you're using. That causes occasional problems, but for the most part it works fine Sounds like the main difference then is the single repo approach involves storing metadata about releases entirely outside of the repo whereas with git the habit is that all the code in the repo goes out together so tags can be used to mark state within the repo.
|
|
#
?
Jan 5, 2019 15:41
|
|
|
From my perspective the main thing a monorepo does is make a much stronger effort at forcing people to stay up-to-date on their dependencies. If you rely on $internal_library, you automatically rely on the version that's at current HEAD. You're expected to have sufficiently thorough automated testing that if they bump their version, then the dependency discovery tools will find your tests and re-run them and that will be sufficient to determine if the version upgrade is safe for you. If you don't have some kind of forcing function like this, then everyone ends up depending on different versions of the libraries, and if a change comes along (whether it's breaking or not) they'll just defer upgrading because hey, what they have works for them and they have a million other things that need to be worked on. And that in turn vastly increases the maintenance burden for the authors of the library. In particular if there's some kind of security vulnerability that gets discovered and then has to be pushed out pronto to all clients, then suddenly the library authors have to code up that fix for every version of the library that anyone depends on, or else use the vulnerability as a hammer to force people to upgrade -- but either way it'll take a lot longer than if they'd been using the most recent version from the get-go. I guess it's totally possible to do this without a monorepo by just having a bunch of smaller repos that all integrate cleanly with each other, but I don't know that that actually buys you anything vs. a monorepo when you have that level of tight integration.
|
|
#
?
Jan 5, 2019 16:28
|
|
|
Question for people who've used monorepos, would they work at smaller-than-google companies? I've always been under the impression that a monorepo was a solution exclusively for large companies, and the bemefits didn't outweigh the cost of the complex tooling and processes at medium and smaller companies.
|
|
#
?
Jan 5, 2019 17:30
|
|
|
Jose Valasquez posted:I don't entirely understand what you are asking but product teams control their own builds/releases. A build is created based on a CL (changelist, essentially a snapshot in time of the monorepo) and deployed. If you've got 5 different services then there will be 5 different setups for the build/deploy process and you can deploy them at different CLs. If your service is directly pulling in a dependency (#include rather than making an RPC to the service) then you get whatever changes were made prior to the CL you're using. That causes occasional problems, but for the most part it works fine So our general approach is to use microservices; one repo is one service. Whenever a team wants to release a service they kick off a build, Jenkins does its thing, and we end up with a tarball and a version tag pushed back to the repo. This way someone can look at the version of a service deployed in production, see the version, and figure out what code it represents. Clearly this pattern doesn't work for a monorepo so I'm curious about how people handle mapping build versions back to code as well as building parts of the repo rather than the whole thing every time there's a change.
|
|
#
?
Jan 5, 2019 17:39
|
|
|
lifg posted:Question for people who've used monorepos, would they work at smaller-than-google companies? Either you're small enough to not need a tools team, or big enough to have one. There's nothing inherently overwhelming about a mid sized monorepo. I'm at a 500 person company and we monorepo with great success. We have a decent amount of tooling for it, but it's 'volunteer' maintained, which will probably transition to be a real team/role relatively soon.
|
|
#
?
Jan 5, 2019 18:04
|
|
|
Blinkz0rz posted:So our general approach is to use microservices; one repo is one service. Whenever a team wants to release a service they kick off a build, Jenkins does its thing, and we end up with a tarball and a version tag pushed back to the repo. This way someone can look at the version of a service deployed in production, see the version, and figure out what code it represents. Builds reference CL numbers. quote:as well as building parts of the repo rather than the whole thing every time there's a change. Different services have different build rules. So if you build the service it only builds the service and its dependencies. It's monorepo not monobuild
|
|
#
?
Jan 5, 2019 18:24
|
|
|
Doom Mathematic posted:Is there an advantage to doing this with a monorepo, though? We do all of the things you mentioned and receive all of the benefits you mentioned, but we don't have a monorepo, we have a bunch of small repos. in a single GHE instance. Aside from the dependency versioning issues of multiple small repos mentioned upthread, with this kind of a workflow you are not really leveraging all of the distributed hotness that makes git interesting. Git is hands down superior for distributed teams that are only in infrequent contact with upstream and with eachother.
|
|
#
?
Jan 5, 2019 19:03
|
|
|
Paolomania posted:Aside from the dependency versioning issues of multiple small repos mentioned upthread, with this kind of a workflow you are not really leveraging all of the distributed hotness that makes git interesting. Git is hands down superior for distributed teams that are only in infrequent contact with upstream and with eachother. Git is so good at distributed redundancy that we had to invent a single source of centralised failure called github.
|
|
#
?
Jan 5, 2019 19:59
|
|
|
TooMuchAbstraction posted:From my perspective the main thing a monorepo does is make a much stronger effort at forcing people to stay up-to-date on their dependencies. If you rely on $internal_library, you automatically rely on the version that's at current HEAD. You're expected to have sufficiently thorough automated testing that if they bump their version, then the dependency discovery tools will find your tests and re-run them and that will be sufficient to determine if the version upgrade is safe for you. alternatively, you end up with multiple copies of dependencies, and a dependency graph that's so horrendous that a hello world program contains 3 javascript interpreters and you need to carry patches on glibc to make it be able to load binaries with 2GB text segments, and then the entire world breaks when someone updates angularJS
|
|
#
?
Jan 6, 2019 00:11
|
|
|
Looking for some tips on my situation. Three months ago, our Data Architect made a political mistake at work and ended up shunned, so I was put in charge of his major projects as Senior Developer. He just quit for another job making more money, and I was handed the rest of his workload, on top of mine which has already been laden with overtime. As he left, he happened to tell me his salary.. 147k, 57k more than I'm making. He reported to the Director, I report to a supervisor below him. I'm planning on going to the Director and asking for the Architect title and a significant pay increase, considering I'm already doing the job. The problem is, his job postings for Data Architect are looking for people with 10+ years of experience, which I'm at half of - I've only been at Senior level for a year, and this is pretty much the final job title in BI work. Anyone been through something like this? I'll probably jump ship from the company if I can't get the title, but wondering if there's anything I should prepare or plan on for this conversation. Another problem is that I'm pretty critical in my current role as the only one capable of supporting half of our production systems, so it's going to be hard to argue that I drop those responsibilities.
|
|
#
?
Jan 6, 2019 00:22
|
|
|
Job listings are bullshit. If you're already doing the job, you have enough experience to do the job. You also have enough experience to look for other jobs at a similar pay scale, so you should make that clear in as blunt a manner as possible.Loutre posted:Another problem is that I'm pretty critical in my current role as the only one capable of supporting half of our production systems, so it's going to be hard to argue that I drop those responsibilities. That's their problem, not your problem.
|
|
#
?
Jan 6, 2019 00:31
|
|
|
Paolomania posted:Aside from the dependency versioning issues of multiple small repos mentioned upthread, with this kind of a workflow you are not really leveraging all of the distributed hotness that makes git interesting. Git is hands down superior for distributed teams that are only in infrequent contact with upstream and with eachother. I admit we have run into the dependency versioning and security issues which TooMuchAbstraction mentioned. For this reason I have, for a long while now, been trying to get all of our UI code, at least, into a single repository. But honestly, I don't think I've ever personally experienced problems which git's distributed hotness would solve. While we do have developers in multiple countries, we are constantly in contact with one another and we deliberately, as department-wide practice, try to keep branches as short-lived as possible. Jaded Burnout posted:Git is so good at distributed redundancy that we had to invent a single source of centralised failure called github. There's also this. The centralized features that we get from GHE are huge. Pull requests with mandatory reviews, integration with Travis CI, integration between PRs and issues (which we use for bug tracking and feature planning), wikis, easy "public" visibility of code to anybody in our organization with a web browser... these things are really valuable. Yeah, it's a single point of failure. Yeah, occasionally the GHE servers need maintenance or go down because of problems, and during that time there's not a lot we can do but develop locally and chat on Slack. Then a few hours later everything is back up again, and it hasn't really slowed us down, so it's not so big a deal. The actual source control system underlying all this is kind of academic.
|
|
#
?
Jan 6, 2019 00:36
|
|
|
Loutre posted:I was handed the rest of his workload, on top of mine which has already been laden with overtime. quote:Another problem is that I'm pretty critical in my current role as the only one capable of supporting half of our production systems, so it's going to be hard to argue that I drop those responsibilities. If I were that confident that even if I got the title and salary I'd still be stuck doing two people's jobs, I'd go find myself a new place of employment where I'd have that title & salary but only one job to do.
|
|
#
?
Jan 6, 2019 03:50
|
|
|
Loutre posted:Anyone been through something like this? I'll probably jump ship from the company if I can't get the title, but wondering if there's anything I should prepare or plan on for this conversation. Another problem is that I'm pretty critical in my current role as the only one capable of supporting half of our production systems, so it's going to be hard to argue that I drop those responsibilities. "You aren't paying me for this second job I've been doing" is all the argument you need and if they really need that work done they'll find a way to pay for it. The reason they aren't is that your price so far has been $0. Obviously you don't need to be combative about it, but that's the core of your argument. You aren't paying off a debt to them, it should be a business relationship. I'd go further of course and work with them to define a reasonable set of responsibilities that results in you not killing yourself with work. If that's not in the cards then get the hell out of there asap.
|
|
#
?
Jan 6, 2019 05:02
|
|
|
THIS FUCKIN GUY rescheduled my meeting with HR for the second time now. I finally went to my boss and asked what this was about, and he said, "CTO probably wants to see what HR's team needs are because they use <internal site that I broke briefly> regularly. They are usually the ones who tell us what links to add or remove. Also the CTO was out for a bit from the holidays so he's had to reschedule a bunch of meetings"
|
|
#
?
Jan 9, 2019 14:15
|
|
|
Sab669 posted:THIS FUCKIN GUY rescheduled my meeting with HR for the second time now. Feel better now?
|
|
#
?
Jan 9, 2019 15:17
|
|
|
Sab669 posted:THIS FUCKIN GUY rescheduled my meeting with HR for the second time now. Oh! Well, I still say  because that's what I always say itt
|
|
#
?
Jan 9, 2019 15:25
|
|
|
New Yorp New Yorp posted:Feel better now? Slightly. I knew I wasn't getting Fired, but I'd be lying if I said I wasn't stressed out last week over this. rt4 posted:Oh! Well, I still say You're definitely right; I won't be making much more money here any time soon, and I'm not learning much. But man the retirement plan here is so good. Also the imposter syndrome is strong, and I struggle with motivation. The company I interviewed with most recently really liked me, and as a coding challenge they want me to make an Imgur-like site - but I'm just struggling to get focused and work on it in the evening. And even if I can complete this, I wonder if I'd actually be a good candidate for this role. I get overwhelmed and discouraged somewhat easily and it sounds like they probably want someone who has better project management skills than I have.
|
|
#
?
Jan 9, 2019 15:34
|
|
|
Wait, your site’s customer is HR? Well... that makes things really different. It makes things worse.
|
|
#
?
Jan 9, 2019 16:12
|
|
|
Glad it's not as bad as you thought but I won't lie I was  'ing this thread hoping for some poo poo to go down.You seem like a pretty good dev, no need to be hard on yourself.
|
|
#
?
Jan 9, 2019 16:24
|
|
|
necrobobsledder posted:Wait, your site’s customer is HR? Well... that makes things really different. It's literally just a static page full of links to different resources. Our software login pages Pay stubs / benefits JIRA Support tickets Docushare A handful of other random links. It's essentially just a "So you don't know how to use Bookmarks" convenience page. And what happened was when someone updated the links to our actual software products, that didn't get checked in. So I pushed a change that added an additional link to some phone queue software for tech support [and overwrote the URLs to the software that clinical support probably uses]. I can't imagine HR ever goes into our software.
|
|
#
?
Jan 9, 2019 16:48
|
|
|
Sab669 posted:It's literally just a static page full of links to different resources. This sounds like the biggest non-issue I've come across in quite some time. And I work very closely with marketers.
|
|
#
?
Jan 9, 2019 16:57
|
|
|
Doom Mathematic posted:I admit we have run into the dependency versioning and security issues which TooMuchAbstraction mentioned. For this reason I have, for a long while now, been trying to get all of our UI code, at least, into a single repository. But honestly, I don't think I've ever personally experienced problems which git's distributed hotness would solve. While we do have developers in multiple countries, we are constantly in contact with one another and we deliberately, as department-wide practice, try to keep branches as short-lived as possible. doesn't fossil allow you to version wikis and issues within the repository itself? I'm sure that has _nooo_ problems when people are trying to edit the wiki at the same time. though I guess no tool can handle that easily
|
|
#
?
Jan 9, 2019 19:36
|
|
|
TooMuchAbstraction posted:Getting comfortable in your career means at least some degree of stagnation. I'm not saying you shouldn't ever feel comfortable -- if you enjoy the work, are sufficiently well-compensated for it, and are reasonably confident that there's long-term demand for your skills, then feel free to stagnate all you like. Just be aware that that's what you're doing. my vague ward / rationalization about why I'm not stagnating is that I'm a generalist and I've done a lot of different jobs all of which require software engineering-type skills and most of which required some math chops. (also despite the variety in work I've stayed in several positions long enough to make it clear that i'm not just jobhopping to remain ahead of the axe, lol) I've gone
|
|
#
?
Jan 9, 2019 19:44
|
|
|
Sab669 posted:and as a coding challenge they want me to make an Imgur-like site 
|
|
#
?
Jan 9, 2019 19:47
|
|
|
Rocko Bonaparte posted:Like, seriously As coding challenges go, I've heard of way worse. Imgur style functionality is pretty easy to duplicate, the secret sauce is handling traffic at scale. and making the site profitable somehow
|
|
#
?
Jan 9, 2019 19:50
|
|
|
Rocko Bonaparte posted:Like, seriously I exaggerate a little bit, the exact request was: * Use pagination to display albums * Be able to click on albums to view thumbnails of images in gallery * Be able to click on users to view their submissions Don't necessarily need to handle uploading images and stuff like that. They wanted me to use this instead of a DB for the project: https://jsonplaceholder.typicode.com/ I'm familiar with working with JSON, obviously, but I'm not sure exactly how to utilize this so it's just one more thing I need to sit down and figure out to work on this. And as I said, sometimes easily overwhelmed  And the requirements they sent me were written very poorly - presumably this was done intentionally to see if I'd speak up / what questions I'd ask for clarification. Sab669 fucked around with this message at 20:38 on Jan 9, 2019 |
|
#
?
Jan 9, 2019 20:35
|
|
|
Sab669 posted:I exaggerate a little bit, the exact request was: Yeah, they're testing out if you know how to write a client that interacts with a RESTful API.
|
|
#
?
Jan 9, 2019 21:19
|
|
|
Remote job search update - After spending 6 hours on a take-home then spending an hour on the phone grilled by four devs, I pushed back when the company said they wanted to spend two hours live pair-programming as well. They didn't bite. - Had a promising interview with an internal recruiter before Christmas. That recruiter got back last week to have me chat with the engineering manager for the company, but after arranging for that interview today I've been ghosted. Recruiter emailed me to say the manager's calls are going straight to my vmail. But I've made outbound and inbound calls this morning, so idk. What a frustrating thing to deal with :| Seemed like there were a lot more remote job postings going up before the holiday break. Hopefully they start showing up more later into the month.
|
|
#
?
Jan 10, 2019 18:03
|
|
|
Got to talk with tech manager later today, ended up going really well. They sent a softball programming challenge I should be able to do in a couple of hours, then fly out to visit for a day before making a hiring decision. I'm looking for full-time remote but this company is asking to spend one week per quarter on site. The city isn't too far from me and it's a city my wife loves, so I think it'll be a good fit.
|
|
#
?
Jan 11, 2019 01:25
|
|
|
Careful Drums posted:I'm looking for full-time remote but this company is asking to spend one week per quarter on site. This is a pretty fair arrangement, really, and it’s been the norm at every remote job I’ve had. It still is important to actually physically show your face every now and then. I like to arrange it so I can do my quarterly goal/perf meetings with my boss in-person.
|
|
#
?
Jan 11, 2019 02:43
|
|
|
a week a quarter is pretty standard yeah. i find i want to go a little more often than that, but it really depends on the team and your role i guess.
|
|
#
?
Jan 11, 2019 02:50
|
|
|
Make sure you can expense the hotel you stay in!
|
|
#
?
Jan 11, 2019 05:31
|
|
|
Depends on what the company's like. Some places are fun to travel to, some coworkers are fun to see in person, some of them make good use of your time so you can get things done while in-person. Other companies are totally gormless and you'll eat dinner alone and go to bed at 9pm.
|
|
#
?
Jan 11, 2019 15:15
|
|
|
rt4 posted:Other companies are totally gormless and you'll eat dinner alone and go to bed at 9pm. And at that point it's time to find a new place to work.
|
|
#
?
Jan 11, 2019 16:10
|
|
|
I usually don't get "regular work" done when I do my quarterly trip to the office, and that's okay. They didn't buy a plane ticket and pay $400/night for a hotel room so I can go heads-down at my desk all day. I can do that at home. I use the time for stuff like coffee catchup meetings with people I work with outside of my team, sitting down for bigger architectural discussions, attending company tech talks that I couldn't do in person, etc. And it's also okay to say fuckit, grab takeout on your way out of the office, and go straight to your hotel. You probably weren't going to go out and play every night if you were home that week. It took me a while of doing weekly business travel to get out of the "I'm on vacation and need to make the most of every minute I'm in this other city" mindset. kitten smoothie fucked around with this message at 23:43 on Jan 11, 2019 |
|
#
?
Jan 11, 2019 23:39
|
|
|
I just had a weeklong overseas trip to meet with teammates and I loved having a quick bite with them after work and then doing my own thing. Also, going to bed at 9 rules.
|
|
#
?
Jan 12, 2019 00:16
|
|
|
|
| # ? Apr 26, 2024 04:23 |
|
|
rt4 posted:Other companies are totally gormless and you'll eat dinner alone and go to bed at 9pm. This sounds ideal.
|
|
#
?
Jan 12, 2019 00:34
|
|
