POPULARITY
2 episodes with gitflow
2 episodes with gitflow
2 episodes with gitflow
2 episodes with gitflow
3 episodes with gitflow
2 episodes with gitflow
2 episodes with gitflow
Tu joues dans quel équipe ? Gitflow ou Trunk based ?Antoine de Pauw remet en question ce qui est devenu un standard : travailler en branches et merge requests.Pourtant, avant git, ça marchait autrement, et peut-être qu'il y avait des choses à garder.Linkedin Thierry : https://www.linkedin.com/in/tdpauw/Flowcon : https://www.flowcon.frHébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.
In this episode, Jeff and Luca discuss trunk-based development, a software development practice where developers merge their work into the main branch (trunk) frequently - at least daily. They explain how this approach differs from traditional branching models like GitFlow, and address common objections and concerns. The hosts emphasize that while trunk-based development may seem risky, it actually reduces risk by exposing integration problems early and forcing teams to implement good engineering practices like automated testing and feature flags.The discussion highlights how trunk-based development acts as a "forcing function" that encourages better development practices, smaller changes, and more frequent collaboration between team members. They explain that while this approach originated in web development, it's equally applicable to embedded systems. The hosts cite research from the book "Accelerate" showing that trunk-based development is a predictor of high-performing software teams.The episode concludes by emphasizing that most objections to trunk-based development actually point to underlying process issues that need to be addressed, and that the benefits of early integration and feedback outweigh the perceived downsides.Timestamps:00:00:00 - Introduction and topic overview00:03:00 - Basic version control concepts and branching00:08:00 - Definition and principles of trunk-based development00:13:00 - Feature flags explanation and implementation00:20:00 - Common objections to trunk-based development00:27:00 - Application to embedded systems00:34:00 - Benefits of trunk-based development00:40:00 - Impact on team dynamics and collaboration00:47:00 - Research backing and evidence from "Accelerate"Shownotes / Links:MinimumCD: https://minimumcd.org/Accelerate: https://www.goodreads.com/book/show/35747076-accelerateThe nvie branching model: https://nvie.com/posts/a-successful-git-branching-model/ You can find Jeff at https://jeffgable.com.You can find Luca at https://luca.engineer.Want to join the agile Embedded Slack? Click here
"Plus il y a de gens, plus Git est efficace" Le D.E.V. de la semaine est Olivier Jacques, consultant ProServe chez Amazon Web Services. Dans cet épisode, nous explorons l'évolution de Git en 2024, alors que nous allons bientôt fêter ses 20 ans. Nous discutons de l'importance de Git dans la gestion du code et examinons plusieurs stratégies d'utilisation au sein des équipes de développement. Olivier présente une typologie de cinq méthodes, comme la stratégie trunk-based, qui favorise l'intégration continue, et aborde les défis liés à chacune d'elles, ainsi que GitFlow, et les branches par environnement (à éviter !). Il met en lumière l'importance du contexte d'équipe et de la culture organisationnelle dans le choix de la stratégie la plus adaptée, tout en soulignant que l'efficacité d'une méthode dépend également de sa mise en &oeliguvre au sein de l'équipe. Liens évoqués pendant l'émission Atlassian : Git workflows.IT Revolution : Accelerate, The Unicorn Project, The Phoenix Project, Team TopologiesGregor Hohpe : Cloud Strategy, Platform Strategy, et son blog sur des sujets d'architecture moderne du logiciel. 🎙️ Soutenez le podcast If This Then Dev ! 🎙️ Chaque contribution aide à maintenir et améliorer nos épisodes. Cliquez ici pour nous soutenir sur Tipeee 🙏Archives | Site | Boutique | TikTok | Discord | Twitter | LinkedIn | Instagram | Youtube | Twitch | Job Board |
(Med Opera röst) Oscar vill släppa till main, Karl vill släppa till main, Mattias vill släppa till main, alla vill släppa till main!Men vad behöver vi ändra i tekniken, verktygen och kulturen för att lyckas?Det här är Git-Flow och GitHub-flowhttps://quangnguyennd.medium.com/git-flow-vs-github-flow-620c922b2cbd Hosted on Acast. See acast.com/privacy for more information.
If you haven't come across Bryan Finster before, you can thank me later. Bryan was one of a small enabling team of 5 people who introduced Continuous Delivery to over 18000 developers at Walmart. He is now working with Defence Unicorns to do the same kind of thing for the US Airforce. Adopting CD at scale is a complicated problem, but Bryan has done it repeatedly, and with intelligence, humour and whit. Amongst many other things, Bryan has started the parody site "Scaled Agile DevOps Maturity Framework" (SADMF) which is worth checking out it you would like a laugh.Here are a few quotes from Bryan: "Developing with CD is fun and productive: not developing with CD is like punching yourself in the face everyday" "It's hard to explain CD to people who have never done it. Like flying cars, If you've never seen CD done, it's hard to believe that it can be true." "Continuous Delivery is not the goal though, it is THE tool for your Excellence Strategy, and to secure your software." "Why do some people fail at adopting CD? You can't just hand people the tools without the training - they will hurt themselves."xx"STOP PUNCHING YOURSELF IN THE FACE"! Learn how to get the CD Mindset, Create Value and Have More Fun, with CD.Training course: "CD: Better Software Faster" ➡️ https://courses.cd.training/courses/c...Get Dave's award-winning book "Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation" ➡️ https://amzn.to/2WxRYmxBryan's Blog Site ➡️ / bdfinst Equal Experts is a product software development consultancy with a network of over 1,000 experienced technology consultants globally. They increase the pace of innovation by using modern software engineering practices that embrace Continuous Delivery, Security, and Operability from the outset ➡️ https://bit.ly/3ASy8n0
Cette semaine, on parle de Git, l'outil de contrôle et de gestion de votre code source. Après un rapide historique, découvrez les cinq patterns d'utilisation de git : GitFlow, des branches par environnement, GitHub flow avec des pull requests, les feature branches et le trunk-based development. Laquelle de ces stratégies de branches pouvez-vous utiliser ? Comment votre stratégie de release ou le type de produit que vous distribuez influence la stratégie de branching ? Et comment les feature flags viennent se brancher sur votre stratégie Git ? On en discute dans l'épisode de cette semaine.
Cette semaine, on parle de Git, l'outil de contrôle et de gestion de votre code source. Après un rapide historique, découvrez les cinq patterns d'utilisation de git : GitFlow, des branches par environnement, GitHub flow avec des pull requests, les feature branches et le trunk-based development. Laquelle de ces stratégies de branches pouvez-vous utiliser ? Comment votre stratégie de release ou le type de produit que vous distribuez influence la stratégie de branching ? Et comment les feature flags viennent se brancher sur votre stratégie Git ? On en discute dans l'épisode de cette semaine.
No episódio de hoje de entre chaves, descobriremos quais são as vantagens e desvantagens de cada abordagem, e qual é a mais adequada para diferentes projetos e equipes. Acompanhe-nos nesta conversa empolgante enquanto mergulhamos no mundo do controle de versão e descobrimos qual estratégia se destaca! Dê o play! Apresentação: Fernanda Vieira e Lucas Campregher Pessoas convidadas: Eduardo Lima, Vinicius Assunção e Marcelo Almeida
Jason Adam is a software with a non-traditional background in biology, business development, and data analytics. Now he's active as a developer, and on the lookout for proven practices he can introduce to his team. On this episode we talk about Trunk-Based Development, and the related topics of continuous integration and deployment, infrastruture as code, and much more.In this episode How Trunk-based development differs from GitFlow and other branching strategies Two flavors of trunk-based development How Trunk-based development fits into the larger picture of continuous integration and continuous delivery Techniques for working in smaller batches How test-driven development enhances trunk-based development Using feature flags for smaller batches How to keep pull requests small Cherry-picking small changes out of a larger pull request How Infrastructure-as-Code works with CI and CD Resources Book: Continuous Delivery by Jez Humble and Dave Farley Book: Domain-Driven Design by Eric Evans Book: Working Effectively with Legacy Code by Michael Feathers Book: Clean Architecture by Robert Martin GuestJason AdamWeb site & newsletter: functionalbits.ioHave a topic to discuss on the show? Let me know!Want a private consultation? Borrow my brain.Watch this episode on YouTube.
About TomTom enjoys being a bridge between people and technology. When he's not thinking about ways to make enterprise demos less boring, Tom enjoys spending time with his wife and dogs, reading, and gaming with friends.Links Referenced: LaunchDarkly: https://launchdarkly.com Heidi Waterhouse Twitter: https://twitter.com/wiredferret TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: Couchbase Capella Database-as-a-Service is flexible, full-featured and fully managed with built in access via key-value, SQL, and full-text search. Flexible JSON documents aligned to your applications and workloads. Build faster with blazing fast in-memory performance and automated replication and scaling while reducing cost. Capella has the best price performance of any fully managed document database. Visit couchbase.com/screaminginthecloud to try Capella today for free and be up and running in three minutes with no credit card required. Couchbase Capella: make your data sing.Corey: This episode is sponsored by our friends at Revelo. Revelo is the Spanish word of the day, and its spelled R-E-V-E-L-O. It means “I reveal.” Now, have you tried to hire an engineer lately? I assure you it is significantly harder than it sounds. One of the things that Revelo has recognized is something I've been talking about for a while, specifically that while talent is evenly distributed, opportunity is absolutely not. They're exposing a new talent pool to, basically, those of us without a presence in Latin America via their platform. It's the largest tech talent marketplace in Latin America with over a million engineers in their network, which includes—but isn't limited to—talent in Mexico, Costa Rica, Brazil, and Argentina. Now, not only do they wind up spreading all of their talent on English ability, as well as you know, their engineering skills, but they go significantly beyond that. Some of the folks on their platform are hands down the most talented engineers that I've ever spoken to. Let's also not forget that Latin America has high time zone overlap with what we have here in the United States, so you can hire full-time remote engineers who share most of the workday as your team. It's an end-to-end talent service, so you can find and hire engineers in Central and South America without having to worry about, frankly, the colossal pain of cross-border payroll and benefits and compliance because Revelo handles all of it. If you're hiring engineers, check out revelo.io/screaming to get 20% off your first three months. That's R-E-V-E-L-O dot I-O slash screaming.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. Today's promoted episode is brought to us by our friends at LaunchDarkly. And it's always interesting when there's a promoted guest episode because they generally tend to send someone who has a story to tell in different ways.Sometimes they send me customers of theirs. Other times they send me executives. And for this episode, they have sent me Tom Totenberg, who's a senior solutions engineer at LaunchDarkly. Tom, thank you for drawing the short straw. It's appreciated.Tom: [laugh]. Anytime. Thank you so much for having me, Corey.Corey: So, you're a senior solutions engineer, which in many different companies is interpreted differently, but one of the recurring themes tends to pop up is often that is a different way of saying sales engineer because if you say sales, everyone hisses and recoils when you enter the conversation. Is that your experience or do you see your role radically differently?Tom: Well, I used to be one of those people who did recoil when I heard the word sales. I was raised in a family where you didn't talk about finances, you know? That's considered to be faux pas, and when you hear the word sales, you immediately think of a car lot. But what I came to realize is that, especially when we talk about cloud software or any sort of community where you start to run into the same people at conferences over and over and over again, turns out the good salespeople are the ones who actually try to form relationships and try to solve problems. And I realized that oh, I like to work with those people. It's pretty exciting. It's nice to be aspirational about what people can do and bring in the technical chops to see if you can actually make it happen. So, that's where I fit in.Corey: The way that I've always approached it has been rather different. Because before I got into tech, I worked in sales a bunch of times and coming up from the—I guess, clawing your way up doing telesales was a polite way of describing—back in the days before there were strong regulations against it, calling people at dinner to sell them credit cards. And what's worse is I was surprisingly effective at it for a kid who, like, you grew up in a family where we didn't talk about money. And it's easy to judge an industry by its worst examples. Another one of these would be recruiting, for example.When everyone talks about how terrible third-party recruiters are because they're referring to the ridiculous spray-and-pray model of just blasting out emails to everything that hold still long enough that meets a keyword. And yeah, I've also met some recruiters that are transformative as far as the conversations you have with them go. But some of that with sales. It's, “Oh, well, you can't be any fun to talk to because I had a really bad experience buying a used car once and my credit was in the toilet.”Tom: Yeah, exactly. And you know, I have a similar experience with recruiters coming to LaunchDarkly. So, not even talking about the product; I was a skeptic, I was happy where I was, but then as I started talking to more and more people here, I'm assuming you've read the book Accelerate; you probably had a hand in influencing part of it.Corey: I can neither confirm nor deny because stealing glory is something I only do very intentionally.Tom: Oh okay, excellent. Well, I will intentionally let you have some of that glory for you then. But as I was reading that book, it reminded me again of part of why I joined LaunchDarkly. I was a skeptic, and they convinced me through everyone that I talked to just what a nice place it is, and the great culture, it's safe to fail, it's safe to try stuff and build stuff. And then if it fails, that's okay. This is the place where that can happen, and we want to be able to continue to grow and try something new.That's again, getting back to the solutions engineer, sales engineer part of it, how can we effectively convey this message and teach people about what it is that we do—LaunchDarkly or not—in a way that makes them excited to see the possibilities of it? So yeah, it's really great when you get to work with those type of people, and it absolutely shouldn't be influenced by the worst of them. Sometimes you need to find the right ones to give you a chance and get in the door to start having those conversations so you can make good decisions on your own, not just try to buy whatever someone's—whatever their initiative is or whatever their priority is, right?Corey: Once upon a time when I first discovered LaunchDarkly, it was pretty easy to describe what you folks did. Feature flags. For longtime listeners of the show, and I mean very longtime listeners of the show, your colleague Heidi Waterhouse was guest number one. So, I've been talking to you folks about a variety of different things in a variety of different ways. But yeah, “LaunchDarkly. Oh, you do feature flags.”And over time that message has changed somewhat into something I have a little bit of difficulty to be perfectly honest with you in pinning down. At the moment we're recording this, if I pull up launchdarkly.com, it says, “Fundamentally change how you deliver software. Innovate faster, deploy fearlessly, and make each release a masterpiece.”And I look at the last release I pushed out, which wound up basically fixing a couple of typos there, and it's like, “Well, shit. Is it going to make me sign my work because I'm kind of embarrassed by a lot of it.” So, it's aspirational, I get it, but it also somehow [occludes 00:05:32] a little bit of meaning. What is it you'd say it is you do here.Tom: Oh, Office Space. Wonderful. Good reference. And also, to take about 30 seconds back, Heidi Waterhouse, what a wonderful human. wiredferret on Twitter. Please, please go look her up. She's got just always such wonderful things to say. So—Corey: If you don't like Heidi Waterhouse, it is a near certainty it is because you've not yet met her. She's wonderful.Tom: Exactly. Yes, she is. So, what is it we'd say we do here? Well, when people think about feature flags—or at this point now, ‘feature management,' which is a broader scope—that's the term that we're using now, it's really talking about that last bit of software delivery, the last mile, the last leg, whatever your—you know, when you're pushing the button, and it's going to production. So, you know, a feature flag, if you ask someone five or ten years ago, they might say, oh, it's a fancy if statement controlled by a config file or controlled by a database.But with a sort of modern architecture, with global delivery, instant response time or fraction of a second response time, it's a lot more fundamental than that. That's why the word fundamental is there: Because it comes down to psychological safety. It comes down to feeling good about your life every day. So, whether it is that you're fixing a couple typos, or if you're radically changing some backend functionality, and trying out some new sort of search algorithm, a new API route that you're not sure if it's going to work at scale, honestly, you shouldn't have to stay up at night, you shouldn't have to think about deploying on a weekend because you should be able to deploy half-baked code to production safely, you should be able to do all of that. And that's honestly what we're all about.Now, there's some extra elements to it: Feedback loops, experimentation, metrics to make sure that your releases are doing well and doing what you anticipated that they would do, but really, that's what it comes down to is just feeling good about your work and making sure that if there is a fire, it's a small fire, and the entire audience isn't going to get part of the splash zone, right? We're making it just a little safer. Does that answer your question? Is that what you're getting at? Or am I still just speaking in the lingo?Corey: That gets it a lot closer. One of the breakthrough moments—of course I picked it up from one of Heidi's talks—is feature flag seems like a front end developer thing, yadda, yadda, yadda. And she said historically, yeah, in some ways, in some cases, that's how it started. But think about it this way. Think about separating out configuration from your deploy process. And what would that mean? What would that entail?And I look at my current things that I have put out there, and there is no staging environment, my feature branches main, and what would that change? In my case, basically nothing. But that's okay. Because I'm an irresponsible lunatic who should not be allowed near anything expensive, which is why I'm better at stateless things because I know better than to take my aura near things like databases.Tom: Yeah. So, I don't know how old you are Corey. But back—Corey: I'm in my mid-30s, which—Tom: Hey—Corey: —enrages my spouse who's slightly older. Because I'm turning 40 in July, but it's like, during the pandemic, as it has for many of us, the middle has expanded.Tom: There you go. Right. Exa—[laugh] exactly. Can neither confirm nor deny. You can only see me from about the mid-torso up, so, you know, you're not going to see whether I've expanded.But when we were in school doing group projects, we didn't have Google Docs. We couldn't see what other people were working on. You'd say, “Hey, we've got to write this paper. Corey, you take the first section, I'll take the second section, and we'll go and write and we'll try to squish it back together afterward.” And it's always a huge pain in the ass, right? It's terrible. Nobody likes group projects.And so the old method of Gitflow, where we're creating these feature branches and trying to squish them back later, and you work on that, and you work on this thing, and we can't see what each other are doing, it all comes down to context switching. It is time away from work that you care about, time away from exciting or productive work that you actually get to see what you're doing and put it into production, try it out. Nobody wants to deal with all the extra administrative overhead. And so yeah, for you, when you've got your own trunk-based development—you know, it's all just main—that's okay. When we're talking about teams of 40, 50, 100, 1000 suddenly becomes a really big deal if you were to start to split off and get away from trunk-based development because there's so much extra work that goes into trying to squish all that work back together, right? So, nobody wants to do all the extra stuff that surrounds getting software out there.Corey: It's toil. It feels consistently like it is never standardized so you always have to wind up rolling your own CI/CD thing for whatever it is. And forget between jobs; between different repositories and building things out, it's, “Oh, great. I get to reinvent the wheel some more.” It's frustrating.Tom: [laugh]. It's either that or find somebody else's wheel that they put together and see if you can figure out where all those spokes lead off to. “Is this secure? I don't know.”Corey: How much stuff do you have running in your personal stuff that has more or less been copied around for a decade or so? During the pandemic, I finally decided, all right, you know what I'm doing? That's right, being productive. We should fix that. I'm going to go ahead and redo my shell config—my zshrc—from scratch because, you know, 15 years of technical debt later, a lot of the things I used to really need it to do don't really apply anymore.Let's make it prettier, and let's make it faster. And that was great and all, but just looking through it, it was almost like going back in time for weird shell aliases that I don't need anymore. It's, well, that was super handy when I ran a Ruby production environment, but I haven't done that in seven years, and I haven't been in this specific scenario that one existed for since 2011. So maybe, maybe I can turn that one off.Tom: Yeah, maybe. Maybe we can get rid of that one. I mean, when's the last time you ran npm install on something you were going to try out here and paid attention to the warnings that came up afterward? “Hey, this one's deprecated. That one's deprecated.” Well, let's see if it works first, and then we'll worry about that later.Corey: Exactly. Security problems? Whatever. It's a Lambda function. What do I care?Tom: Yeah, it's fine. [laugh]. Exactly. Yeah. So, a lot of this is hypothetical for someone in my position, too, because I didn't ever get formal training as a software developer. I can copy and paste from Stack Overflow with the best of them and there's all sorts of resources out there, but really the people that we're talking to are the ones who actually live that day in, day out.And so I try to step into their shoes and try to feel that pain. But it's tough. Like, you have to be able to speak both languages and try to relate to people to see what are they actually running into, and is that something that we can help with? I don't know.Corey: The way that I tend to think about these things—and maybe it's accurate, and maybe it's not—it's just, no one shows up hoping to do a terrible job at work today, but we are constrained by a whole bunch of things that are imposed upon us. In some of the more mature environments, some of that is processes there for damn good reasons. “Well, why can't I just push everything I come up with to production?” “It's because we're a bank, genius. How about you think a little bit before you open your mouth?”Other times, it's because well, I have to go and fight with the CI/CD system, and I'm just going to go ahead and patch this one-line change into production. Better processes, better structure have made that a lot more… they've made it a lot easier to be able to do things the right way. But I would say we're nowhere near its final form, yet. There's so much yak-shaving that has to go into building out anything that it's frustrating, on some level, just all of the stuff you have to do, just to get the scaffolding in place to write nonsense. I mean, back when they announced Lambda functions it was, “In the future, the only code you'll write is business logic.”Yeah, well, I use a crap-ton of Lambda here and it feels like most of the code I write is gluing all of the weird formats and interchanges together in different APIs. Not a lot of business logic in that; and awful lot of JSON finickiness.Tom: Yeah, I'm with you. And especially at scale, I still have a hard time wrapping my mind around how all of that extra translation is possibly going to give the same sort of performance and same sort of long-term usability, as opposed to something that just natively speaks the same language end-to-end. So yeah, I agree, there's still some evolution, some standardization that still needs to happen because otherwise we're going to end up with a lot of cruft at various points in the code to, just like you said, translate and make sure we're speaking the same language.Getting back to process though, I spent a good chunk of my career working with companies that are, I would say, a little more conservative, and talking to things like automotive companies, or medical device manufacturers. Very security-conscious, compliant places. And so agile is a four-letter word for them, right, [laugh] where we're going faster automatically means we're being dangerous because what would the change control board say? And so there's absolutely a mental shift that needs to happen on the business side. And developers are fighting this cultural battle, just to try to say, hey, it's better if we can make small iterative changes, there is less risk if we can make small, more iterative changes, and convincing people who have never been exposed to software or know the ins and outs of what it takes to get something from my laptop to the cloud or production or you know, wherever, then that's a battle that needs to be fought before you can even start thinking about the tooling. Living in the Midwest, there's still a lot of people having that conversation.Corey: So, you are clearly deep in the weeds of building and deploying things into production. You're clearly deep into the world of explaining various solutions to different folks, and clearly you have the obvious background for this. You majored in music. Specifically, you got a master's in it. So, other than the obvious parallel of you continue to sing for your supper, how do you get from there to here?Tom: Luck and [laugh]. Natural curiosity. Corey, right now you are sitting on the desk that is also housing my PC gaming computer, right? I've been building computers just to play video games since I was a teenager. And that natural curiosity really came in handy because when I—like many people—realize that oh, no, the career choice that I made when I was 18 ended up being not the career choice that I wanted to pursue for the rest of my life, you have to be able to make a pivot, right, and start to apply some of the knowledge that you got towards some other industries.So, like many folks who are now solutions engineers, there's no degree for solutions engineering, you can't go to school for it; everyone comes from somewhere else. And so in my case, that just happened to be music theory, which was all pedagogy and teaching and breaking down big complex pieces of music into one node at a time, doing analysis, figuring out what's going on underneath the hood. And all of those are transferable skills that go over to software, right? You open up some giant wall of spaghetti code and you have to start following the path and breaking it down because every piece is easy one note at a time, every bit of code—in theory—is easy one line at a time, or one function at a time, one variable at a time. You can continue to break it down further and further, right?So, it's all just taking the transferable skills that you may not see how they get transferred, but then bringing them over to share your unique perspective, because of your background, to wherever it is you're going. In my case, it was tech support, then training, and then solutions engineering.Corey: There's a lot to be said for blending different disciplines. I think that there was, uh, the naughts at least, and possibly into the teens, there was a bias for hiring people who look alike. And no, I'm not referring to the folks who are the white dudes you and I clearly present as but the people with a similar background of, “Oh, you went to these specific schools”—as long as they're Stanford—“And you majored in a narrow list of things”—as long as they're all computer science. And then you wind up going into the following type of role because this is the pedigree we expect and everything, soup to nuts, is aligned around that background and experience. Where you would find people who would be working in the industry for ten years, and they would bomb the interview because it turns out that most of us don't spend our days implementing quicksort on whiteboards or doing other algorithmic-based problems.We're mostly pushing pixels around a screen hoping to make ourselves slightly happier than we were. Here we are. And that becomes a strange world; it becomes a really, really weird moment, and I don't know what the answer is for fixing any of that.Tom: Yeah, well, if you're not already familiar with a quote, you should be, which is that—and I'm going to paraphrase here—but, “Diverse backgrounds lead to diversity in thought,” right? And that presents additional opportunities, additional angles to solve whatever problems you're encountering. And so you're right, you know, we shouldn't be looking for people who have the specific background that we are looking for. How it's described in Accelerate? Can you tell that I read it recently?Which we should be looking for capabilities, right? Are you capable? Do you have the capacity to do the problem-solving, the logic? And of course, some education or experience to prove that, but are you the sort of person who will be able to tackle this challenge? It doesn't matter, right, if you've handled that specific thing before because if you've handled that specific thing before, you're probably going to implement it the same way, again, even if that's not the appropriate solution, this time.So, scrap that and say, let's find the right people, let's find people who can come up with creative solutions to the problems that we're facing. Think about ways to approach it that haven't been done before. Of course don't throw out everything with the—you know, the bathwater out with a baby or whatever that is, but come in with some fresh perspectives and get it done.Corey: I really wish that there was more of an acceptance for that. I think we're getting there. I really do, but it takes time. And it does pay dividends. I mean, that's something I want to talk to you about.I love the sound of my own voice. I wouldn't have two podcasts if I didn't. The counterargument, though, is that there's an awful lot of things that get, you know, challenging, especially when, unlike in a conference setting, it's most people consider it rude to get up and walk out halfway through. When we're talking and presenting information to people during a pandemic situation, well, that changes a lot. What do you do to retain people's interest?Tom: Sure. So, Covid really did a number on anyone who needs to present information or teach. I mean, just ask the millions of elementary, middle school, and high schoolers out there, even the college kids. Everyone who's still getting their education suddenly had to switch to remote learning.Same thing in the professional world. If you are doing trainings, if you're doing implementation, if you're doing demos, if you're trying to convey information to a new audience, it is so easy to get distracted at the computer. I know this firsthand. I'm one of those people where if I'm sitting in an airport lobby and there's a TV on my eyes are glued to that screen. That's me. I have a hard time looking away.And the same thing happens to anyone who's on the receiving end of any sort of information sharing, right? You got Slack blowing you up, you've got email that's pinging you, and that's bound to be more interesting than whatever the person on the screen is saying. And so I felt that very acutely in my job. And there's a couple of good strategies around it, right, which is, we need to be able to make things interactive. We shouldn't be monologuing like I am doing to you right now, Corey.We shouldn't be [laugh] just going off on tangents that are completely irrelevant to whoever's listening. And there's ways to make it more interactive. I don't know if you are familiar, or how much you've watched Twitch, but in my mind, the same sorts of techniques, the same sorts of interactivity that Twitch streamers are doing, we should absolutely be bringing that to the business world. If they can keep the attention of 12-year-olds for hours at a time, why can we not capture the attention of business professionals for an hour-long meeting, right? There's all sorts of techniques and learnings that we can do there.Corey: The problem I keep running into is, if you go stumbling down that pathway into the Twitch streaming model, I found it awkward the few experiments I've made with it because unless I have a whole presentation ready to go and I'm monologuing the whole time, the interactive part with the delay built in and a lot of ‘um' and ‘ah' and waiting and not really knowing how it's going to play out and going seat of the pants, it gets a little challenging in some respects.Tom: Yeah, that's fair. Sometimes it can be challenging. It's risky, but it's also higher reward. Because if you are monologuing the entire time, who's to say that halfway through the content that you are presenting is content that they want to actually hear, right? Obviously, we need to start from some sort of fundamental place and set the stage, say this is the agenda, but at some point, we need to get feedback—similar to software development—we need to know if the direction that we're going is the direction they also want to go.Otherwise, we start diverging at minute 10 and by minute 60, we have presented nothing at all that they actually want to see or want to learn about. So, it's so critical to get that sort of feedback and be able to incorporate it in some way, right? Whether that way is something that you're prepared to directly address. Or if it's something that says, “Hey, we're not on the same page. Let's make sure this is actually a good use of time instead of [laugh] me pretending and listening to myself talk and not taking you into account.” That's critical, right? And that is just as important, even if it feels worse in the moment.Corey: This episode is sponsored in part by our friends at ChaosSearch. You could run Elasticsearch or Elastic Cloud—or OpenSearch as they're calling it now—or a self-hosted ELK stack. But why? ChaosSearch gives you the same API you've come to know and tolerate, along with unlimited data retention and no data movement. Just throw your data into S3 and proceed from there as you would expect. This is great for IT operations folks, for app performance monitoring, cybersecurity. If you're using Elasticsearch, consider not running Elasticsearch. They're also available now in the AWS marketplace if you'd prefer not to go direct and have half of whatever you pay them count towards your EDB commitment. Discover what companies like Equifax, Armor Security, and Blackboard already have. To learn more, visit chaossearch.io and tell them I sent you just so you can see them facepalm, yet again.Corey: From where I sit, one of the many, many, many problems confronting us is that there's this belief that everyone is like we are. I think that's something fundamental, where we all learn in different ways. I have never been, for example—this sounds heretical sitting here saying it, but why not—I'm not a big podcast person; I don't listen to them very often, just because it's such a different way of consuming information. I think there are strong accessibility reasons for there to be transcripts of podcasts. That's why every 300-and-however-many-odd episodes that this one winds up being the sequence in, every single one of them has a transcript attached to it done by a human.And there's a reason for that. Not just the accessibility wins which are obvious, but the fact that I can absorb that information way more quickly if I need to review something, or consume that. And I assume other people are like me, they're not. Other people prefer to listen to things than to read them, or to watch a video instead of listening, or to build something themselves, or to go through a formal curriculum in order to learn something. I mean, I'm sitting here with an eighth-grade education, myself. I take a different view to how I go about learning things.And it works for me, but assuming that other people learn the same way that I do will be awesome for a small minority of people and disastrous for everyone else. So, maybe—just a thought here—we shouldn't pattern society after what works for me.Tom: Absolutely. There is a multiple intelligence theory out there, something they teach you when you're going to be a teacher, which is that people learn in different ways. You don't judge a fish by its ability to climb a tree. We all learn in different ways and getting back to what we were talking about presenting effectively, there needs to be multiple approaches to how those people can consume information. I know we're not recording video, but for everyone listening to this, I am waving my hands all over the place because I am a highly visual learner, but you must be able to accept that other people are relying more on the auditory experience, other people need to be able to read that—like you said with the accessibility—or even get their hands on it and interact with it in some way.Whether that is Ctrl-F-ing your way through the transcript—or Command-F I'm sorry, Mac users [laugh]; I am also on a Mac—but we need to make sure that the information is ready to be consumed in some way that allows people to be successful. It's ridiculous to think that everyone is wired to be able to sit in front of a computer or in a little cubicle for eight hours a day, five days a week, and be able to retain concentration and productivity that entire time. Absolutely not. We should be recording everything, allowing people to come back and consume it in small chunks, consume it in different formats, consume it in the way that is most effective to them. And the onus for that is on the person presenting, it is not on the consumer.Corey: I make it a point to make what I am doing accessible to the people I am trying to reach, not to me. And sometimes I'm slacking, for example, we're not recording video today, so whenever it looks like I'm not paying attention to you and staring off to the side, like, oh, God, he's boring. No. I have the same thing mirrored on both of my screens; I just prefer to look at the thing that is large and easy to read, rather than the teleprompter, which is a nine-inch screen that is about four feet in front of my face. It's one of those easier for me type of things.On video, it looks completely off, so I don't do it, but I'm oh good, I get to take the luxury of not having to be presentable on camera in quite the same way. But when I'm doing a video scenario, I absolutely make it a point to not do that because it is off-putting to the people I'm trying to reach. In this case, I'm not trying to reach you; I already have. This is a promoted guest episode you're trying to reach the audience, and I believe from what I can tell, you're succeeding, so please keep at it.Tom: Oh, you bet. Well, thank you. You know this already, but this is the very first podcast I've ever been a guest on. So, thank you also for making it such a welcoming place. For what it's worth, I was not offended and didn't think you weren't listening. Obviously, we're having a great time here.But yeah, it's something that especially in the software space, people need to be aware of because everyone's job is—[laugh]. Whether you like it or not, here's a controversial statement: Everyone's job is sales. Are you selling your good ideas for your product, to your boss, to your product manager? Are you able to communicate with marketing to effectively say, “Hey, this is what, in tech support, I'm seeing. This is what people are coming to me with. This is what they care about.”You are always selling your own performance to your boss, to your customers, to other departments where you work, to your spouse, to everybody you interact with. We're all selling ourselves all the time. And all of that is really just communication. It's really just making sure you're able to meet people where they are and, effectively, bridge your point of view with theirs to make sure that we're on the same page and, you know, we're able to communicate well. That's so especially important now that we're all remote.Corey: Just so you don't think this is too friendly of a place, let's go ahead and finish out the episode with a personal attack. Before you wound up working at LaunchDarkly. You were at Perforce. What's up with that? I mean, that seems like an awfully big company to cater to its single customer, who is of course J. Paul Reed.Tom: [laugh]. Yeah. Well, Perforce is a wonderful place. I have nothing but love for Perforce, but it is a very different landscape than LaunchDarkly, certainly. When I joined Perforce, I was supporting product called Helix ALM, which, they're still headquartered—Perforce is headquartered here in Minneapolis. I just saw some Perforce folks last week. It truly is a great place, and it is the place that introduced me to so many DevOps concepts.But that's a fair statement. Perforce has been around for a while. It has grown by acquisition over the past several years, and they are putting together new offerings by mixing old offerings together in a way that satisfies more modern needs, things like virtual production, and game development, and trying to package this up in a way that you can then have a game development environment in a box, right? So, there's a lot of things to be said for that, but it very much is a different landscape than a smaller cloud-native company. Which it's its own learning curve, let me tell you, but truly, yeah, to your Perforce, there's a lot more complexity to the products themselves because they've been around for a little bit longer.Solid, solid products, but there's a lot going on there. And it's a lot harder to learn them right upfront. As opposed to something like LaunchDarkly, which seems simple on the surface and you can get started with some of the easy concepts in implementation in, like, an hour, but then as you start digging deeper, whoof, suddenly, there's a lot more complexity hidden underneath the surface than just in terms of how this is set up, and some of those edge cases.Corey: I have to say for the backstory, for those who are unfamiliar, is I live about four miles away from J. Paul Reed, who is a known entity in reliability engineering, in the DevOps space, has been for a long time. So, to meet him, of course I had to fly to Israel. And he was keynoting DevOpsDays Tel Aviv. And I had not encountered him before, and it was this is awesome, I loved his talk, it was fun.And then I gave a talk a little while later called, “Terrible Ideas in Git.” And he's sitting there just glaring at me, holding his water bottle that is a branded Perforce thing, and it's like, “Do you work there?” He's like, “No. I just love Perforce.” It's like, “Congratulations. Having used it, I think you might be the only one.”I kid. I kid. It was great and a lot of different things. It was not quite what I needed when I needed it to but that's okay. It's gotten better and everyone else is not me, as we've discussed; people have different use cases. And that started a very long-running joke that J. Paul Reed is the entirety of the Perforce customer base.Tom: [laugh]. Yeah. And to your point, there's definitely use cases—you're talking about Perforce Version Control or Helix Core.Corey: Back in those days, I don't believe it was differentiated.Tom: It was just called Perforce. Exactly right. But yeah, as Perforce has gotten bigger, now there's different product lines; you name it. But yeah, some of those modern scalable problems, being able to handle giant binary files, being able to do automatic edge replication for globally distributed teams so that when your team in APAC comes online, they're not having to spend the first two hours of their day just getting the most recent changes from the team in the Americas and Europe. Those are problems that Perforce is absolutely solving that are out there, but it's not problems that everybody faces and you know, there's just like everybody else, we're navigating the landscape and trying to find out where the product actually fits and how it needs to evolve.Corey: And I really do wish you well on it. I think there's going to be an awful lot of—Tom: Mm-hm.Corey: —future stories where there is this integration. And you'd say, “Oh, well, what are you wishing me well for? I don't work there anymore.” But yeah, but isn't that kind of we're talking about, on some level, of building out things that are easy, that are more streamlined, that are opinionated in the right ways, I suppose. And honestly, that's the thing that I found so compelling about LaunchDarkly. I have a hard time imagining I would build anything for production use that didn't feature it these days if I were, you know, better at computers?Tom: Sure. Yeah. [laugh]. Well, we do have our opinions on how some things should work, right? Where the data is exposed because with any feature flagging system or feature management—LaunchDarkly included—you've got a set of rules, i.e. who should see this, where is it turned on? Where is it turned off? Who in your audience or user base should be able to see these features? That's the rules engine side of it.And on the other side, you've got the context to decide, well, you know, I'm Corey, I'm logging in, I'm in my mid-30s. And I know all this information about Corey, and those rules need to then be able to determine whether something should be on or off or which experience Corey gets. So, we are very opinionated over the architecture, right, and where that evaluation actually happens and how that data is exposed or where that's exposed. Because those two halves need to meet and both halves have the potential to be extremely sensitive. If I'm targeting based off of a list of 10,000 of my premium users' email addresses, I should not be exposing that list of 10,000 email addresses to a web browser or a mobile phone.That's highly insecure. And inefficient; that's a large amount of text to send, over 10,000 email addresses. And so when we're thinking about things like page load times, and people being able to push F12 to inspect the page, absolutely not, we shouldn't be exposing that there. At the same time, it's a scary prospect to say, “Hey, I'm going to send personal information about Corey over to some third-party service, some edge worker that's going to decide whether Corey should see a feature or not.” So, there's definitely architectural considerations of different use cases, but that's something that we think through all the time and make sure is secure.There's a reason—I'm going to put on my sales engineer hat here—which is to say that there is a reason that the Center for Medicare and Medicaid Services is our sponsor for FedRAMP moderate certification, in process right now, expected to be completed mid-2022. I don't know. But anybody who is unfamiliar with that, if you've ever had to go through high trust certification, you know, any of these compliances to make your regulators happy, you know that FedRAMP is so incredibly stringent. And that comes down to evaluating where are we exposing the data? Who gets to see that? Is security built in and innate into the architecture? Is that something that's been thought through?I have went so far afield from the original point that you made, but I agree, right? We've got to be opinionated about some things while still providing the freedom to use it in a way that is actually useful to you and [laugh] and we're not, you know, putting up guardrails, that mean that you've got such a narrow set of use cases.Corey: I'd like to hope—maybe I'm wrong on this—that it gets easier the more that we wind up doing these things because I don't think that it necessarily has been easy enough for an awful lot of us.Tom: When you say ‘it,' what do you mean?Corey: All of it. That's the best part, I suppose the easy parts of working on computers, which I guess might be typing if you learn it early enough.Tom: Sure. [laugh] yeah. Mario Teaches Typing, or Starcraft taught me how to type quickly. You can't type slowly or else your expansion is going to get destroyed. No, so for someone who got their formal education in music or for someone with an eighth-grade education, I agree there needs to be resources out there.And there are. Not every single StackOverflow post with a question that's been asked has the response, “That's a dumb question.” There are some out there. There's definitely a community or a group of folks who think that there is a correct way to do things and that if you're asking a question, that it's a dumb question. It really isn't. It's getting back to the diverse backgrounds and diverse schools of thought that are coming in.We don't know where someone is coming from that led them to that question without the context, and so we need to continue providing resources to folks to make it easy to self-enable and continue abstracting away the machine code parts of it in friendlier and friendlier ways. I love that there are services like Squarespace out there now, right, that allow anybody to make a website. You don't have to have a degree in computer science to spin something up and share it with the world on the web. We're going to continue to see that type of abstraction, that type of on-ramp for folks, and I'm excited to be part of it.Corey: I really look forward to it. I'm curious to see what happens next for you, especially as you continue—‘you' being the corporate ‘you' here; that's like the understood ‘you' are the royal ‘you.' This is the corporate ‘you'—continue to refine the story of what it is LaunchDarkly does, where you start, where you stop, and how that winds up playing out.Tom: Yeah, you bet. Well, in the meantime, I'm going to continue to play with things like GitHub Copilot, see how much I can autofill, and see which paths that takes me down?Corey: Oh, I've been using it for a while. It's great. Just tab-complete my entire life. It's amazing.Tom: Oh, yeah. Absolutely.Corey: [unintelligible 00:36:08] other people's secrets start working, great, that makes my AWS bill way lower when I use someone else's keys. But that's neither here nor there.Tom: Yeah, exactly. That's a next step of doing that npm install or, you know, bringing in somebody else's [laugh] tools that they've already made. Yeah, just a couple weeks ago, I was playing around with it, and I typed in two lines: I imported the LaunchDarkly SDK and the configuration for the LaunchDarkly SDK, and then I just let it autofill, whatever it wanted. It came out with about 100 lines of something or other. [laugh]. And not all of it made sense, but hey, I saw where the thought process was. It was pretty cool to see.Corey: I really want to thank you for spending as much time and energy as you have talking about how you see the world and where you folks are going. If people want to learn more. Where's the best place to find you?Tom: At launchdarkly.com. Of course, any other various different booths, DevOpsDays, we're at re:Invent, we're at QCon right now. We're at all sorts of places, so come stop by, say hi, get a demo. Maybe we'll talk.Corey: Excellent. We will be tossing links to that into the [show notes 00:37:09]. Thanks so much for your time. I really appreciate it.Tom: Corey, Thank you.Corey: Tom Totenberg, senior solutions engineer at LaunchDarkly. I'm Cloud Economist Corey Quinn and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice along with an angry and insulting comment, and then I'll sing it to you.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.
Dziś porównujemy Gitflow i Trunk Based Development. Czym różnią się te podejścia? Które działają w jakich sytuacjach? Jak mają się do projektów komercyjnych?
Quando Giulio ed il sottoscritto hanno iniziato a lavorare i sistemi di source control erano pochi e rozzi. Spesso lo "zippone" con i sorgenti era il modo per fare versioning. Oggi il mondo è cambiato.Il problema non è come fare versioning, piuttosto quale strategia di versioning usare: GitFlow, GitHub Flow, Release Flow, o Trunk Based development sono alcune tra le opzioni sul tavolo.Oh mamma mia, che confusione. Cerchiamo di mettere ordine nella complessità.Riferimenti bibliografici:- Rochkind, Marc J. “The Source Code Control System.” IEEE Transactions on Software Engineering SE-1, no. 4 (December 1975): 364–70. https://doi.org/10.1109/TSE.1975.6312866.- Appleton, Brad, Berczuk, Stephen, Cabrera, Ralph, and Orenstein, Robert. “Streamed Lines: Branching Patterns for Parallel Software Development.” Pattern Languages of Programs, February 8, 1998. http://www.hillside.net/plop/plop98/final_submissions/P37.pdf.- Cabrera, Ralph, Appleton, Brad, and Berczuk, Stephen. “Software Reconstruction: Patterns for Reproducing Software Builds.” Pattern Languages of Programs, 1999. https://hillside.net/plop/plop/plop99/proceedings/cabrera/softwarereconstruction.pdf.- https://martinfowler.com/articles/branching-patterns.html
Nachdem wir vor Kurzem gemerkt haben, dass sich unsere Branching und Release Strategien stark unterscheiden, möchten wir diese heute einmal in Ruhe vergleichen, sowie die Vor- und Nachteile besprechen. In dieser Folge geht es daher neben den grundsätzlichen Vorteilen von Feature Branches und Pull Requests, um eine Gegenüberstellung von GitFlow und GitHub Flow. Links: Git patterns and anti-patterns talk: https://www.youtube.com/watch?v=ykZbBD-CmP8 Atlassian über GitFlow: https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow GitHub über GitHub Flow: https://docs.github.com/en/get-started/quickstart/github-flow GitLab über GitLab Flow, sowie GitFlow und GitHub Flow: https://docs.gitlab.com/ee/topics/gitlab_flow.html
Today on the show we will be talking about Git Workflows. It seems like everybody is always using Gitflow or Trunk Based Development. Gitflow defines a strict branching model designed around the project release. It assigns very specific roles to different branches and defines how and when they should interact. Trunk Based Development is a source-control branching model, where developers collaborate on code in a single branch called ‘trunk'. Advances to source-control technologies have made Trunk Based Development more (and sometimes less) prevalent. However, it has been a branching model that many have stuck with through the years. In this episode we'll be getting into more of what we prefer, whether it is Gitflow or Trunk Based Development and we'll get to some of the pros and cons behind the two.
You can find Jeff at https://jeffgable.com.You can find Luca at https://luca.engineer. The Git-Flow branching model: https://nvie.com/posts/a-successful-git-branching-model/
Bora falar sobre uma das ferramentas que mais ajuda os devs no desenvolvimento dos projetos? E como é o fluxo e as possibilidades de uso? No episódio de hoje, falamos sobre o que é o git, a importância de versionar um código e como funciona o gitflow! Chega+ e bora ouvir esse episódio, que tá massa! --- Edição completa por Rádiofobia Podcast e Multimídia: https://radiofobia.com.br/ --- Nos siga no Twitter e no Instagram: @luizalabs @cabecadelab Dúvidas, cabeçadas e sugestões, mande e-mail para o cabecadelab@luizalabs.com Participantes: Ariadyne Oliveira | @trescores Milene Mancini Vasconcelos | instagram.com/m_mvasconcelos/ William Machado | linkedin.com/in/william-fernando-balan-machado-a36bb333
En este episodio nos acompañan Carlos Muñoz Villar, César Díez e Iñaki Villar, todos compañeros en Tinder, y con los que charlamos sobre cultura de empresa, sobre cómo es posible tener un equipo entero para el onboarding, herramientas internas, modularización, Git Flow vs. Trunk Based Development y mucho más.A los mandos está Nicolás Patarino (@npatarino) y si querés conocer de primera mano cómo es ser parte de un equipazo como el de Tinder, metele play y escuchá todo lo que tienen para contar. --- Send in a voice message: https://podcasters.spotify.com/pod/show/chimichurri/message
Jeder Entwickler nutzt es täglich aber was genau ist git und was ist GitFlow? Und welche Rolle spielt dieses GitHub in dem ganzen. In dieser Folge versuchen wir all diese Fragen zu beantworten.
No episódio de hoje a Ana fala sobre fluxo de trabalho com o Git, ou Gitflow, uma prática adotada por muitas empresas! O post PodProgramar #88 – Trabalhando com fluxo no Git apareceu primeiro em Mundo Podcast.
No episódio de hoje a Ana fala sobre fluxo de trabalho com o Git, ou Gitflow, uma prática adotada por muitas empresas! O post PodProgramar #88 – Trabalhando com fluxo no Git apareceu primeiro em Mundo Podcast.
KonukBurak Selim Şenyurt - https://www.linkedin.com/in/burak-selim-%C5%9Fenyurt-b15537ab/Linkler- Doğuş Teknoloji GitHub - https://github.com/DogusTeknoloji- Doğuş Teknoloji - https://www.d-teknoloji.com.tr/- Burak Şenyurt GitHub - https://github.com/buraksenyurt/skynetNeler Konuştuk? - Doğuş Teknoloji'de kullanılan teknolojiler ve yazılım dilleri- Neden eski teknolojiler kullanılıyor?- Modüler uygulamalara geçiş- IT for IT ne demek?- Backend/Frontend/Devops ayrımı- Ekiplerin yapısı- Geliştiricilerin teknik konulardaki yaklaşımları- Dokümantasyon yazmaya yaklaşımları- Analistler ile yazılımcılar birlikte nasıl çalışıyor?- Test yaklaşımları ve süreçleri- Gitflow kullanım şekilleri- Neden fazla test yazmıyorlar- Code review süreçleri- Üretim ortamında bug varsa yapılanlar- Yük testleri yapılışları- Legacy kodu daha iyi hale getirmek- Fazla mesai- Rollback süreçleri- Exception monitoring- Açık kaynak yaklaşımları- Kişisel teknik blog yazmak- Geliştirici motivasyonunu yüksek tutmak- Developer chapter nedir?- Uzaktan çalışma ve pandemi süreci- Geliştirici onboarding süreçleri- İşe alım süreçleri
KonukBurak Selim Şenyurt - https://www.linkedin.com/in/burak-selim-%C5%9Fenyurt-b15537ab/Linkler- Doğuş Teknoloji GitHub - https://github.com/DogusTeknoloji- Doğuş Teknoloji - https://www.d-teknoloji.com.tr/- Burak Şenyurt GitHub - https://github.com/buraksenyurt/skynetNeler Konuştuk? - Doğuş Teknoloji'de kullanılan teknolojiler ve yazılım dilleri- Neden eski teknolojiler kullanılıyor?- Modüler uygulamalara geçiş- IT for IT ne demek?- Backend/Frontend/Devops ayrımı- Ekiplerin yapısı- Geliştiricilerin teknik konulardaki yaklaşımları- Dokümantasyon yazmaya yaklaşımları- Analistler ile yazılımcılar birlikte nasıl çalışıyor?- Test yaklaşımları ve süreçleri- Gitflow kullanım şekilleri- Neden fazla test yazmıyorlar- Code review süreçleri- Üretim ortamında bug varsa yapılanlar- Yük testleri yapılışları- Legacy kodu daha iyi hale getirmek- Fazla mesai- Rollback süreçleri- Exception monitoring- Açık kaynak yaklaşımları- Kişisel teknik blog yazmak- Geliştirici motivasyonunu yüksek tutmak- Developer chapter nedir?- Uzaktan çalışma ve pandemi süreci- Geliştirici onboarding süreçleri- İşe alım süreçleri
Luc-Olivier reviews the AirPods Pro.Related LinksFU: The Icon Garden 33: The Measure of a Mac with Special Guest Merlin MannFU; George Stocker: Please stop recommending Git Flow!FU: Ata Distance: QR Apple Pay Cards for iOS 14 Wallet?FU: Ata Distance: On the eve of iOS 13.4FU: Ata Distance: iOS 13.4: Apple Pay Suica making way for Mobile PASMO?FU: FeliCaDude: Mobile PASMO: the "me-too" that's all about them, and not youFU: Basically Guide to Better BakingFU: Use Gelatin to Improve Pan Sauces, Store-Bought Stocks, and Beyond | Serious EatsAirPods Pro - Apple (CA)AirPods - Apple (CA)Powerbeats Pro - Beats by DreLuc-Olivier’s previous earphones: BeatsX - Beats by DreYanik’s current wireless headphones: Beats Solo³ sans fil – Beats by Dr. Dre
Как там дела за океаном Два слова про Remote Удаленный Кофебрейк +) brain.fm George Stocker — Please stop recommending Git Flow! TensorFlow Enterprise «Икигай. Смысл жизни по-японски» Ken Mogi — The Little Book of Ikigai Участники @golodnyj @b0noi Благодарности патронам: Aleksandr Kiriushin, Alex Malikov, Fedor Rusak, Grigori Pivovar, Ihor Kopyl, Lagunovsky Ivan, Leo Kapanen, Mikhail Gaidamaka, Neikist, nikaburu, Pavel Drabushevich, Pavel Sitnikov, Sergey Kiselev, Sergey Vinyarsky, Sergii Zhuk, Vasiliy Galkin Telegram канал Поддержи подкаст Подпишись в iTunes Подпишись без iTunes Скачай подкаст Старые выпуски
In this episode we have covered:Coronavirus Please Stop Recommending git flow DigitalOcean Container Registry“Let’s use Kubernetes!” Now you have 8 problems
Cet épisode parle du coronavirus, des conférences annulées, de la popularité des langages, de GraphQL, de Ghostcat et pleins d’autres choses encore. L’intro date un peu: les infos sur le coronavirus étant encore plus fréquentes que les nouveaux framework JavaScript. Enregistré le 13 mars 2020 Téléchargement de l’épisode LesCastCodeurs-Episode–227.mp3 News Corona virus Les actions des grosses boites pas de meeting conf annulées limite du travail au bureau Langages RedMonk ranking - Le langage au top est… JavaScript Python Java Typescript dans le top 10 R monte Rust stable comme Go (+1) Kotlin 19, Scala 13 InfoQ meta sondage Java 8 le plus déployé en prod, 25% Java 11 et non LTS derrière Spring 60–80% IntelliJ 60–80%, Eclipse 20–25% mavenjvs Gradle 66–33 ou 50–50 Sondage sur Scala Scala.js 1.0.0 7 ans de dev not binary compatible with 0.6 nor 1.0RCx Ecrire en scala des applications front interop avec les libraries JavaScript GraalVM se dote d’un advisory board Gluon, Red Hat, Amazon, Microdoc, Shopify, Twitter, OCI, Neo4J, Pivotal, ARM et Oracle bien sûr Gros round d’investissement dans Azul investissement / achat: 340 M$ Librairies Eclipse MicroProfile GraphQL 1.0 GraphQL: spec pour generaliser les endpoints en leur donnat lflexibilite en terme de requetage et graph retourné make GraphSQL schema available execute GraphQL requests code first approach Apache Camel 3.1 et 3.0 déprécié Le guide de migration de Camel amélioration de mémoire Lightbend recoit 25M d’investissement de Dell capital pour la partie reactive spécifiquement pour le “serverless” pas de mention de Scala OPTIONNEL LightBend - Article sur pourquoi une architecture reactive est importante pour le cloud native bonne piqure de rappel data localisée par microservice les avantages des systèmes event based Middleware ElasticSearch en prod, les choses a savoir les concepts de base (Clusters, Nodes, Indices and Shards) Quorum comment des noeuds rejoingnent le cluster segments et le merge gestion de la memoire (compressed pointers /! inversé, 30GB, 2x memoire sur la machine par rapport au heap) voir https://stackoverflow.com/questions/25120546/trick-behind-jvms-compressed-oops#25120926 options par workload (write heavy vs read heavy topology monitoring Infrastructure La M&A de have i been p0wned: l’histoire de l’abandon societe KPMG due diligence des milliards de questions les doutes exclusivité le risque du changement de stratégie Cloud Les gens ralent car les clusters GKE vont avoir un cout de management de 10c/heure, ce qui change la relation du cluster au développeur (nombre de clusters en parallèle) Une comparaison des prix des clusters en fonction de leur taille et de leur host provider Amazon annonce Bottlerocket Mise a jour par image recrée plutôt que par package mis a jour plus immuable et donc facile en rollback par contre chaque host goes down et up si orchestrateur c’est ok Outillage IntelliJ Big Data Tools un IDE pour le big data! deja integration avec Zeppelin S3 nouveau Spark, HDFS, Paquet Architecture Les systèmes simples ont moins de downtime facile à comprendre, facile à corriger plus rapide de monter en competence trouver la cause est plus rapide solutions simples, plus d’alternatives disponibles regles: les fonctionalités de justifient pas la complexité, les idées complexes amènent des implémentations complexes, modifier avant d’ajouter challenge de l’automation pour faire avec moins de gens? OPTIONNEL 11 raisons pour lesquelles vous allez rater vos microservices voir les titres de section OPTIONNEL Retour d’experience sur l’usage incorrect d’un outil bloom filters probleme idéal pour bloom filters mais suspicieusement plus long que prévu profilers random access memory >> sequential reading (trop grand pour L3) alternative plus simple qui reduit le nombre le chargement memoire, pas la conso memoire Méthodologies Les trains de merge rebasing, la course au collègue garder master green pour la CD impossible de faire trops de merge en parallele ou doit faire pleins de rebase merge train sequentialise et batch les merges Retour sur le modèle GitFlow pas intuitif (merge bidirectionels dans le temps entre develop, feature branch, release branch, hotfix et master) et cout cognitif haut risque grandi de merge conflit peut pas rebaser continuous delivery != trop de barrières en cas de repos multiples ou mono repos, impossible a gérer (microservices) ok pour des cycles de release par trimestre avec des equipes sur des releases en parallele Mesure de la complexité de code: une meilleure mesure cyclomatic complexité est un mauvais oracle de la complexité de code les logiques conditionnelles emboîtées utilisent notre mémoire de travail (~indentation) les fonctions avec des dos d’anes d’indentation multiples sont les pires refactorer pour externaliser chaque Dans Sonarqube cela s’appelle Cognitive Complexity. Voici un exemple sur du code XWiki ou l’on voit très bien visuelement ce que cela veut dire: https://sonarcloud.io/project/issues?id=org.xwiki.commons%3Axwiki-commons&issues=AWzY6RXo8pMOHxUYvkyE&open=AWzY6RXo8pMOHxUYvkyE Sécurité Ghostcat: la faille dans Tomcat de 6 à 9 dans le protocole Apache JServ (implicitement trusté par Tomcat (cs une requête) peut lire le contenu des web apps si la webapp peut uploader => activer un remote execution upgrader Tomcat 7, 8, 9, si 6, vous êtes dans la merde attention Tomcat est embarqué dans pleins d’outils comme Wildfly, Spring Boot etc Letencrypt révoque 3 millions de certs a multiples domaines Loi, société et organisation Amicus brief sur le copyright d’API par IBM et Red Hat computer interfaces ne sont pas copyrightable moteur de l’economie du logiciel va etre entendu au printemps Amicus brief de chercheurs attaqué par Oracle payés par Google OPTIONNEL Les hackers de Equifax contamnés pour crime DOJ charcge 4 militaires Chinois Struts CVE Rubrique débutant La tonte de Yak appliquée à Donarld Knuth écrire un livre écrire un programme pour ecrire un livre invente un langage de programmation pour écrire le programme invente un mode de pagination design une police de caractère écrit un outil pour construire les polices de caractère invente un système de version pour son programme implémente un langage d’abstraction maison pour les documents imprimés Conférences ANNULÉ - Breizhcamp du 25 au 27 mars 2020 ANNULÉ - MiXiT du 29 au 30 avril 2020 VIRTUEL - GitHub Satellite les 6 et 7 mai ANNULÉ - RivieraDev du 13 au 15 mai 2020 Devoxx UK du 13 au 15 mai 2020 NewCrafts les 28 et 29 mai 2020 AlpesCraft les 4 et 5 juin 2020 ANNULÉ - Best of Web les 4 et 5 juin 2020 DevFest Lille le 12 juin 2020 - (Le CFP est ouvert) Voxxed Days Luxembourg du 17 au 19 juin 2020 ANNULÉ - Serverless Days Paris le 1 juillet 2020 NOUVELLE DATE - Devoxx France du 1 au 3 juillet 2020 Sunny Tech les 2 et 3 juillet 2020 Et encore plus sur Developers Conferences Agenda/List …. Liste d’Aurélie Nous contacter Soutenez Les Cast Codeurs sur Patreon https://www.patreon.com/LesCastCodeurs Faire un crowdcast ou une crowdquestion Contactez-nous via twitter https://twitter.com/lescastcodeurs sur le groupe Google https://groups.google.com/group/lescastcodeurs ou sur le site web https://lescastcodeurs.com/
Cet épisode parle du coronavirus, des conférences annulées, de la popularité des langages, de GraphQL, de Ghostcat et pleins d'autres choses encore. L'intro date un peu: les infos sur le coronavirus étant encore plus fréquentes que les nouveaux framework JavaScript. Enregistré le 13 mars 2020 Téléchargement de l'épisode [LesCastCodeurs-Episode-227.mp3](https://traffic.libsyn.com/lescastcodeurs/LesCastCodeurs-Episode-227.mp3) ## News ### Corona virus Les actions des grosses boites * pas de meeting * conf annulées * limite du travail au bureau ### Langages [RedMonk ranking - Le langage au top est...](https://redmonk.com/sogrady/2020/02/28/language-rankings-1-20/) * JavaScript Python Java * Typescript dans le top 10 * R monte * Rust stable comme Go (+1) * Kotlin 19, Scala 13 [InfoQ meta sondage](https://www.infoq.com/news/2020/02/developer-surveys/) * Java 8 le plus déployé en prod, 25% Java 11 et non LTS derrière * Spring 60-80% * IntelliJ 60-80%, Eclipse 20-25% * mavenjvs Gradle 66-33 ou 50-50 [Sondage sur Scala](https://scalacenter.github.io/scala-developer-survey-2019/) [Scala.js 1.0.0](https://www.scala-js.org/news/2020/02/25/announcing-scalajs-1.0.0/) * 7 ans de dev * not binary compatible with 0.6 nor 1.0RCx * Ecrire en scala des applications front * interop avec les libraries JavaScript [GraalVM se dote d'un advisory board](https://jaxenter.com/graalvm-project-advisory-board-168885.html?utm_source=twitter&utm_medium=social&utm_campaign=1week) * Gluon, Red Hat, Amazon, Microdoc, Shopify, Twitter, OCI, Neo4J, Pivotal, ARM et Oracle bien sûr [Gros round d'investissement dans Azul](https://www.azul.com/press_release/azul-systems-announces-strategic-growth-equity-investment-by-vitruvian-partners/) * investissement / achat: 340 M$ ### Librairies [Eclipse MicroProfile GraphQL 1.0](https://microprofile.io/2020/02/25/microprofile-graphql-1-0-released/) * GraphQL: spec pour generaliser les endpoints en leur donnat lflexibilite en terme de requetage et graph retourné * make GraphSQL schema available * execute GraphQL requests * code first approach [Apache Camel 3.1 et 3.0 déprécié](https://camel.apache.org/blog/release-3-1-0.html) [Le guide de migration de Camel](https://camel.apache.org/manual/latest/camel-3x-upgrade-guide.html) * amélioration de mémoire [Lightbend recoit 25M d'investissement](https://www.benzinga.com/pressreleases/20/03/g15505587/lightbend-closes-25-million-investment-round-led-by-dell-technologies-capital#/.XmZXZGRo7yc.twitter) * de Dell capital * pour la partie reactive * spécifiquement pour le "serverless" * pas de mention de Scala OPTIONNEL [LightBend - Article sur pourquoi une architecture reactive est importante pour le cloud native](https://www.lightbend.com/blog/stateful-cloud-native-applications-why-reactive-matters) * bonne piqure de rappel * data localisée par microservice * les avantages des systèmes event based ### Middleware [ElasticSearch en prod, les choses a savoir](https://facinating.tech/2020/02/22/in-depth-guide-to-running-elasticsearch-in-production/) * les concepts de base (Clusters, Nodes, Indices and Shards) * Quorum * comment des noeuds rejoingnent le cluster * segments et le merge * gestion de la memoire (compressed pointers /! inversé, 30GB, 2x memoire sur la machine par rapport au heap) voir * options par workload (write heavy vs read heavy * topology * monitoring ### Infrastructure [La M&A de have i been p0wned: l'histoire de l'abandon](https://www.troyhunt.com/project-svalbard-have-i-been-pwned-and-its-ongoing-independence/) * societe KPMG * due diligence * des milliards de questions * les doutes * exclusivité * le risque du changement de stratégie ### Cloud Les gens ralent car les clusters GKE vont avoir un cout de management de 10c/heure, ce qui change la relation du cluster au développeur (nombre de clusters en parallèle) [Une comparaison des prix des clusters en fonction de leur taille et de leur host provider](https://devopsdirective.com/posts/2020/03/managed-kubernetes-comparison/) Amazon annonce [Bottlerocket](https://aws.amazon.com/fr/bottlerocket/) * Mise a jour par image recrée plutôt que par package mis a jour * plus immuable et donc facile en rollback * par contre chaque host goes down et up * si orchestrateur c'est ok ### Outillage [IntelliJ Big Data Tools](https://blog.jetbrains.com/blog/2020/02/25/update-on-big-data-tools-plugin-spark-hdfs-parquet-and-more/) * un IDE pour le big data! * deja integration avec Zeppelin S3 * nouveau Spark, HDFS, Paquet ### Architecture [Les systèmes simples ont moins de downtime](https://www.gkogan.co/blog/simple-systems/?r=0) * facile à comprendre, facile à corriger * plus rapide de monter en competence * trouver la cause est plus rapide * solutions simples, plus d'alternatives disponibles * regles: les fonctionalités de justifient pas la complexité, les idées complexes amènent des implémentations complexes, modifier avant d'ajouter * challenge de l'automation pour faire avec moins de gens? OPTIONNEL [11 raisons pour lesquelles vous allez rater vos microservices](https://medium.com/xebia-engineering/11-reasons-why-you-are-going-to-fail-with-microservices-29b93876268b) * voir les titres de section OPTIONNEL [Retour d'experience sur l'usage incorrect d'un outil bloom filters](https://blog.cloudflare.com/when-bloom-filters-dont-bloom/) * probleme idéal pour bloom filters * mais suspicieusement plus long que prévu * profilers * random access memory >> sequential reading (trop grand pour L3) * alternative plus simple qui reduit le nombre le chargement memoire, pas la conso memoire ### Méthodologies [Les trains de merge](https://about.gitlab.com/blog/2020/01/30/all-aboard-merge-trains/) * rebasing, la course au collègue * garder master green pour la CD * impossible de faire trops de merge en parallele ou doit faire pleins de rebase * merge train sequentialise et batch les merges [Retour sur le modèle GitFlow](https://georgestocker.com/2020/03/04/please-stop-recommending-git-flow/) * pas intuitif (merge bidirectionels dans le temps entre develop, feature branch, release branch, hotfix et master) et cout cognitif haut * risque grandi de merge conflit * peut pas rebaser * continuous delivery != trop de barrières * en cas de repos multiples ou mono repos, impossible a gérer (microservices) * ok pour des cycles de release par trimestre avec des equipes sur des releases en parallele [Mesure de la complexité de code: une meilleure mesure](https://empear.com/blog/bumpy-road-code-complexity-in-context/) * cyclomatic complexité est un mauvais oracle de la complexité de code * les logiques conditionnelles emboîtées utilisent notre mémoire de travail (~indentation) * les fonctions avec des dos d'anes d'indentation multiples sont les pires * refactorer pour externaliser chaque Dans Sonarqube cela s'appelle Cognitive Complexity. Voici un exemple sur du code XWiki ou l'on voit très bien visuelement ce que cela veut dire: ### Sécurité [Ghostcat: la faille dans Tomcat de 6 à 9](https://snyk.io/blog/ghostcat-breach-affects-all-tomcat-versions/) * dans le protocole Apache JServ (implicitement trusté par Tomcat (cs une requête) * peut lire le contenu des web apps * si la webapp peut uploader => activer un remote execution * upgrader Tomcat 7, 8, 9, si 6, vous êtes dans la merde * attention Tomcat est embarqué dans pleins d'outils comme Wildfly, Spring Boot etc [Letencrypt révoque 3 millions de certs a multiples domaines](https://thehackernews.com/2020/03/lets-encrypt-certificate-revocation.html?m=1#click=https://t.co/zViFYyMIse) ### Loi, société et organisation [Amicus brief sur le copyright d'API par IBM et Red Hat](https://www.redhat.com/en/blog/red-hat-urges-us-supreme-court-support-unrestricted-use-software-interfaces) * computer interfaces ne sont pas copyrightable * moteur de l'economie du logiciel * va etre entendu au printemps [Amicus brief de chercheurs attaqué par Oracle](https://twitter.com/joshbloch/status/1237507340514889729) * payés par Google OPTIONNEL [Les hackers de Equifax contamnés pour crime](https://www.infoq.com/news/2020/02/equifax-charges/?utm_campaign=infoq_content&utm_source=twitter&utm_medium=feed&utm_term=java) * DOJ charcge 4 militaires Chinois * Struts CVE ## Rubrique débutant [La tonte de Yak appliquée à Donarld Knuth](https://yakshav.es/the-patron-saint-of-yakshaves/) * écrire un livre * écrire un programme pour ecrire un livre * invente un langage de programmation pour écrire le programme * invente un mode de pagination * design une police de caractère * écrit un outil pour construire les polices de caractère * invente un système de version pour son programme * implémente un langage d'abstraction maison pour les documents imprimés ## Conférences ANNULÉ - [Breizhcamp du 25 au 27 mars 2020](https://www.breizhcamp.org/) ANNULÉ - [MiXiT du 29 au 30 avril 2020](https://mixitconf.org/) VIRTUEL - [GitHub Satellite les 6 et 7 mai](https://githubsatellite.com/) ANNULÉ - [RivieraDev du 13 au 15 mai 2020](https://rivieradev.fr/) [Devoxx UK du 13 au 15 mai 2020](https://www.devoxx.co.uk/) [NewCrafts les 28 et 29 mai 2020](http://ncrafts.io/) [AlpesCraft les 4 et 5 juin 2020](https://www.alpescraft.fr/) ANNULÉ - [Best of Web les 4 et 5 juin 2020](http://bestofweb.paris/) [DevFest Lille le 12 juin 2020](https://devfest.gdglille.org/) - (Le [CFP](https://conference-hall.io/public/event/4o1awYXIRayhu3vmOmiQ) est ouvert) [Voxxed Days Luxembourg du 17 au 19 juin 2020](https://luxembourg.voxxeddays.com/) ANNULÉ - [Serverless Days Paris le 1 juillet 2020](https://paris.serverlessdays.io/en/) NOUVELLE DATE - [Devoxx France du 1 au 3 juillet 2020](https://www.devoxx.fr/) [Sunny Tech les 2 et 3 juillet 2020](https://sunny-tech.io/) Et encore plus sur [Developers Conferences Agenda/List](https://github.com/scraly/developers-conferences-agenda/blob/master/README.md) .... [Liste d'Aurélie](https://github.com/scraly/developers-conferences-agenda) ## Nous contacter Soutenez Les Cast Codeurs sur Patreon [Faire un crowdcast ou une crowdquestion](https://lescastcodeurs.com/crowdcasting/) Contactez-nous via twitter sur le groupe Google ou sur le site web
Otras charlas de la CAS 2019 también en podcast: https://lk.autentia.com/CAS19-Podcast ------------- Desde el momento en el que nos planteamos el desarrollo del software para resolver un problema intentamos aplicar las ""mejores prácticas"", pero lo buenas que sean estas prácticas dependen mucho del momento en el que se encuentre el proyecto. No es lo mismo intentar crear un MVP que tener un producto consolidado dando servicio a miles de clientes de pago, ni un equipo consolidado y maduro que estar montándolo y tener que trabajar en el mismo equipo. Cada momento tiene sus mejores prácticas y hay que saber emplear la técnica adecuada en el momento correcto. Desde ese punto de vista se plantea esta sesión, revisando las mejores prácticas dentro del desarrollo ágil de software bajo el prisma de su utilidad dentro de un proyecto y con la perspectiva del momento de madurez en el que se encuentra ese proyecto. Repasaremos prácticas como pruebas automáticas, integración continua pasando por despliegue continuo y entrega continua, Git Flow, refactoring, propiedad colectiva del código, pair programming, Todo esto desde mi experiencia de más de 20 años dentro de la industria y del ejemplo de Sherpa (sherpa.ai), que es la empresa donde actualmente desarrollo mi labor intentando crear el mejor producto posible dentro del mundo de los asistentes personales predictivos.
Feature branching is again gaining in popularity due to the rise of distributed version control systems. Although branch creation has become very easy, it comes with a specific cost. Long living branches break the flow of the software delivery process, impacting throughput and stability, but does it also affect the quality of our domain model? Join us with Thierry de Pauw in this Virtual DDD sessions to explore with us how feature branching can impact domain-driven design. Because one of the critical aspects of DDD is to keep gaining new insights together to create a rich and rigid domain model. For this, we need fast feedback which could be disabled by feature branching.
Gavin and Brad host this weeks episode.They talk about CF Summit 2019 Vegas releasing more videos from the sessions on YouTube. The playlist has 14 videos already. They talk about qB and the latest release v7.1.0 after last weeks v7.0.0 was released. We also remind you to sign up for Rakshith's upcoming Webinar on CF2020. They discuss deadlines for workshops and call for speakers for Into the Box 2020 in Houston in May, so try and submit your ideas by the end of the year... as well as some other conferences you should consider attending. They spotlight a lot of great blog posts, tweets, videos and podcasts, too many to list, so listen to the show. They show off our ForgeBox module of the Week, Brad's WireBox Visualizer and this week's VS Code extensions, GitFlow. We finish the podcast thank our Patreon supporters, and wishing everyone a happy new year and we'll see you next year. For the show notes - visit the website https://cfmlnews.modernizeordie.io/episodes/modernize-or-die-cfml-news-for-december-31st-2019 Music from this podcast used under Royalty Free license from SoundDotCom https://www.soundotcom.com/ and BlueTreeAudio https://bluetreeaudio.com
In this episode, from a remote location in beautiful Asheville, NC, I talk about Git and all the basic commands that someone would need to understand in order to start using the tool.
En este episodio quiero comentarte acerca del GitFlow y sobre la importancia de su uso en un entorno de desarrollo, bien sea para trabajar solo o con un equipo de trabajo. Estaré explicandote la importancia de su uso, sus principios y sobre como aplicarlo en tus proyectos. Además te estaré recomendando algunas herramientas que puedes utilizar para gestionar GIT en tus proyectos. Y recuerda que si tienes alguna duda o sugerencia, o si simplemente quieres recomendarme algún tema que te interese, sígueme en mi twitter @fjugaldev. También puedes escribir a mi correo fjugal.dev@franciscougalde.com Visita mi blog para más contenido exclusivo! --> www.franciscougalde.com
In this episode, we discuss the San Francisco Giants Calendar, Git Flow, IntelliJ, Illuminated Cloud, and managing your release environments.
In this episode Jason Westerhouse shares details on how KeyBank is integrating Dynatrace across their DevOps toolchain and driving automated quality gates, continuous feedback and faster incident response time by embracing GitFlow – using Jenkins, containers and release automation to automate CD.
In this episode Jason Westerhouse shares details on how KeyBank is integrating Dynatrace across their DevOps toolchain and driving automated quality gates, continuous feedback and faster incident response time by embracing GitFlow – using Jenkins, containers and release automation to automate CD.
In this episode Jason Westerhouse shares details on how KeyBank is integrating Dynatrace across their DevOps toolchain and driving automated quality gates, continuous feedback and faster incident response time by embracing GitFlow – using Jenkins, containers and release automation to automate CD.
In this episode Jason Westerhouse shares details on how KeyBank is integrating Dynatrace across their DevOps toolchain and driving automated quality gates, continuous feedback and faster incident response time by embracing GitFlow – using Jenkins, containers and release automation to automate CD.
I femte avsnittet av UTVECKLA diskuterar vi Gitflow med vår erfarna och kunniga konsult, tillika konsultchef, Jonas Klingstedt! Highligths: 00:34 HEJ! 07:59 Välkommen, Jonas Klingstedt! 11:01 Vad är Gitflow? 23:12 Vad finns det för liknande arbetssätt? 27:01 Kommentarer som systemdokumentation? 39:32 Git i andra verktyg? 44:19 Vad är stash? 49:35 Tobbes läxförhör 55:11 Let’s trap it up! Länktips: A successful Git branching model Atlassian: Become a git guru Kontakta oss gärna på utveckla@consid.se och glöm inte att joina eftersnacksgruppen på Facebook! Vi vill också passa på att rikta ett stort tack till Lars Netzel - vår eminenta kollega som ligger bakom poddens episka jinglar!
Conversamos con Borja Quevedo sobre buenas prácticas en git en https://www.danielprimo.io/podcast/66Calendario de Adviento de Web Reactiva https://calendario.webreactiva.com- Newsletter: https://www.danielprimo.io/newsletter- Twitter: https://twitter.com/webreactiva- Telegram: https://t.me/webreactiva
Conversamos con Borja Quevedo sobre buenas prácticas en git en https://www.danielprimo.io/podcast/66Calendario de Adviento de Web Reactiva https://calendario.webreactiva.com- Newsletter: https://www.danielprimo.io/newsletter- Twitter: https://twitter.com/webreactiva- Telegram: https://t.me/webreactiva
This week, Jeffrey and Squirrel answer a question from CruiseControl founder Paul Julius about what agile practises they've left behind. Surprising answers include iterations, predictability, and planning. SHOW LINKS: - PJ: http://www.pauljulius.com/ - Abnormally terminating a sprint - https://www.mountaingoatsoftware.com/blog/making-the-decision-to-abnormally-terminate-a-sprint - Kanban: https://en.wikipedia.org/wiki/Kanban_(development) - Elephant Carpaccio: http://alistair.cockburn.us/Elephant+carpaccio - Searching for an Agile Core: https://blog.jeffreyfredrick.com/2008/11/08/searching-for-an-agile-core/ - Planning Game: https://en.wikipedia.org/wiki/Extreme_programming_practices#Planning_game - TDD: https://www.amazon.co.uk/Test-Driven-Development-Addison-Wesley-Signature/dp/0321146530 - Cruise Control: http://cruisecontrol.sourceforge.net/ - GitFlow: https://datasift.github.io/gitflow/IntroducingGitFlow.html - Chris Matts: https://theitriskmanager.wordpress.com/ *** We'd love to hear any thoughts, ideas or feedback you have regarding the show. Email us: see link on troubleshootingagile.com Tweet us: twitter.com/TShootingAgile Also, if you'd like to leave us a review on iTunes (or just like and subscribe), you'll find us here: https://itunes.apple.com/gb/podcast/troubleshooting-agile/id1327456890?mt=2
En el podcast de hoy hemos hablado sobre sistemas de control de versiones, Git, GitHub, algunos concepto básicos, sus flujos de trabajo, algunos consejos y buenas prácticas, GUIs e integraciones con editores... En fin, esperamos que os guste! Blog Entredevyops : http://www.entredevyops.es Twitter Entredevyops: https://twitter.com/EntreDevYOps Enlaces comentados: La guia del autoestopista galactico: https://es.wikipedia.org/wiki/Gu%C3%ADa_del_autoestopista_gal%C3%A1ctico_(libro) Podcast BeSuricata: https://besuricata.com/ Python PEP8: https://www.python.org/dev/peps/pep-0008/ Git: https://git-scm.com/ Comparación de Git y Mercurial: https://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/ GitHub: https://github.com/ GitHub Marketplace: https://github.com/marketplace/ Gitlab: https://gitlab.com/ Bitbucket: https://bitbucket.org/ Sourced: https://sourced.tech/ Tutorial Merging vs Rebase: https://www.atlassian.com/git/tutorials/merging-vs-rebasing Gitflow: http://nvie.com/posts/a-successful-git-branching-model/ GitHub Flow: https://guides.github.com/introduction/flow/ Extensión de Gitflow para el CLI de git: https://github.com/petervanderdoes/gitflow-avh CLI oficial de GitHub: https://github.com/github/hub gitsome, CLI para trabajar con GH: https://github.com/donnemartin/gitsome git-spindle, extensión de GitHub para el CLI de git: https://github.com/seveas/git-spindle Magit: https://magit.vc/ CodeClimate: https://codeclimate.com/ Travis-ci: https://travis-ci.org/
Neste episódio, Victor Nascimento e Rafael Toledo seguem o papo e conversam sobre Application Lifecycle, Git Flow, Integração Contínua e um monte de outras coisas!
Git is an amazing version control system. Very popular and extremely powerful. Git flow is a branching strategy for git which can make setting development and devops practices very easy. In this podcast we see what Git flow is and how it helps. A little bit more about git flow: http://nikhilwanpal.in/blog/podcast-tech-nuggets-and-thoughts-episode-2-intro-to-git-flow
Todd, Chris, and Jess chat about using Git in their day-to-day lives. Jess thinks it's the best thing since the CPU, but Todd thinks it's just the shiny new toy that's no better than TFS. Meanwhile, Chris thinks that GitFlow is the most overly-complicated process he's ever seen. What do you think?
Today on the show we will be talking about Git Workflows. It seems like everybody is always using Gitflow or Trunk Based Development. Gitflow defines a strict branching model designed around the project release. It assigns very specific roles to different branches and defines how and when they should interact. Trunk Based Development is a source-control branching model, where developers collaborate on code in a single branch called ‘trunk'. Advances to source-control technologies have made Trunk Based Development more (and sometimes less) prevalent. However, it has been a branching model that many have stuck with through the years. In this episode we'll be getting into more of what we prefer, whether it is Gitflow or Trunk Based Development and we'll get to some of the pros and cons behind the two.
In this episode of the Zero Index podcast, Chris and Lucian talk all things git.
La gestion de versions du code source - Comment gérer les flux de travail autour du code ?
This week Mark and Gordon chat about their respective git workflows, Swift operator precedence groups, and a general uneasiness around the tooling in the iOS ecosystem (but what else is new?). GitFlow PR adding precedence groups to Runes PR adding precedence groups to Argo PR for using the project generated by swift package manger in Curry
Взрослый подход к большим проектам в инфраструктурных вопросах и вопросах тестирования. Поделимся опытом адаптации gitflow к реалиям динамичной разработки мобильных приложений. Построим самый удобный Continuous Integration сервер. Пройдемся по Continuous Delivery и даже Continuous Translations И запустим на нем все тесты, которые только можно сделать, чтобы постоянно проверять наш код.
Wordpress started using React, Flux, node and all sorts of modern stuff. Micro services, json-api and more on git.
Yo what up #BenAndAbhi nation! Show num-beer 3 is here. We talk about Git & Git-Flow... What front-end prototyping tools to use under different circumstances and Abhi drops some solid wisdom on prepping for your first technical interview.
Thu, 25 Jun 2015 06:30:00 +0000 https://www.protokollcast.de/24-werkzeug 729e546b6786357a7f861e3bc191a267 Gitflow und warum "Considered Harmful" schädlich ist. Warum ein "Considered Harmful" Artikel schädlich ist, warum man seine Werkzeuge kennen sollte und was das ganze mit Git und Gitflow zu tun hat, ist Thema dieser Ausgabe. Die Links für diese Sendung: End of Line Blog “Considered Harmful” Essays Considered Harmful Re: [git pull] drm-next scottchacon.com Commit Often, Perfect Later, Publish Once—Git Best Practices gitworkflows(7) https://images.podigee.com/0x,sPHgeBCNlCulv2cq-WbEqs3aP9vQ8lkACQLlcY77uhEg=/https://cdn.podigee.com/uploads/u301/1435211684d0fa.jpg Werkzeug https://www.protokollcast.de/24-werkzeug 24 full Gitflow und warum "Considered Harmful" schädlich ist. no Marc Kalmes
Part one of a multi-part series on open source. Today we discuss open source & code management with a version control system & explore the concept of git-flow.
Scotty and John chat about the release of Reviewcast, Paper for Facebook and GitFlow with GitHub
In this episode, we talk to Mick Wever about how they migrating a big team of developers from Subversion to Git.Mick has been involved with various open source projects since ancient times, and during the day time he’s working for FINN, which is Norway’s dominating classifieds website. The company has a very interesting story, and we investigate how and why they were able to make the switch to Git. If you cannot see the audio controls, your browser does not support the audio element. Use the link below to download the mp3 manually. Link to mp3Links:Mick on GitHub, Twitter Scarab issue trackerFINN’s Tech blogMick's article about their Git migrationPackage Management conflicts Continuous DeliveryApache TilesApache’s Git mirrorsAtlassian's article on migration from SVN to GitSubGit Stash pluginThe Flow of Change (techtalk from Google)GitHub Flow vs Git Flow Practical API Design (book)NetBeans API blogConfigure git pull to rebase:git config --global branch.master.rebase truegit config --global branch.autosetuprebase alwaysMick's favorite log format:git config --global alias.lol "log --follow --find-copies-harder --graph --abbrev=4 --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %Cgreen%ai %n %C(bold blue)%aN%Creset %B'"A lot of other nice aliases and configuration tips we talked about can be found at the bottom of the FINN blog post under the section 'Tips and tricks for beginners…'.Listen to the episode on YouTube
In this episode we talk to Ryan Hodson, the man behind Ry's Git Tutorial. If you cannot see the audio controls, your browser does not support the audio element. Use the link below to download the mp3 manually. Link to mp3Links:RyPress.comRy’s Git Tutorial Try GitPeter Cottle's "Learn Git Branching"The Git Users' Mailing ListGit FlowGitHub FlowTreehouse (online learning)Atlassian’s Git blog postsGitHub's Free Office HoursJinja templatesInstalling Git manual web pagesIf you want to see the help for git-status, you can do either of these:git status --help git help status On Windows/Msysgit, the default is to always open the web page. If you are on Mac or Linux, you can append -w to the above commands.If you always want to see the web pages (so you can leave out -w), you can do:git config --global help.format webOn my Mac, Lynx was the default browser for some reason, so I had to configure it to use the OSX `open` command (for html files) instead:git config --global web.browser openOn my Ubuntu machine, I had to configure it like this to use Google Chrome (Firefox was default):git config --global web.browser google-chromeI also had to clone the docs into this location (not the one according to the GitHub help pages above):/usr/share/doc/git/html/See git-web--browse docs for more info.Listen to the episode on YouTube
In this episode we talk to Richard Schneeman, or Schneems, about Git branches and workflows. If you cannot see the audio controls, your browser does not support the audio element. Use the link below to download the mp3 manually. Link to mp3Links:Schneem's homepageCodeTriage (Help your favorite open source projects!)Heroku (Schneems works here)Schneem's famous GIF pull-requestSchneem’s Git intro (note all the great Rails tutorials in his YouTube channel)Git Flow vs Github FlowContributing to Rails guide (describes the CHANGELOG, etc)Schneem's favorite git command:git config -e Listen to the episode on YouTube
© 2020-2025 Ivy Podcast Discovery LLC
