Opens profile photo
Follow
Click to Follow ojacques2
🌤️livier Jacques
@ojacques2
DevOps at AWS. I tweet about DevOps, CI/CD, upskilling, cloud ⛅, documentation engineering 📖, paragliding 🪂 and my music 🎹. Opinions are my own.
Grenoble, France 🌄ojacques.github.ioJoined April 2009
1,569 Following
870 Followers

🌤️livier Jacques’s Tweets

🌤️livier Jacques Retweeted
Paul Johnston - current focus: moving electrons
@PaulDJohnston
I want to highlight this thread because it's a classic of its genre. Blaming a "word" and their understanding of it for what are clearly team, architecture, design and process issues. Lots of people who do serverless at scale coming in and telling them they're wrong (inc me).
Quote Tweet
Boris Tane 🍋
@BorisTane
I spoke with a team yesterday that is moving away from serverless in favor of managed k8s on aws it wasn't an easy decision for them and they went through a thorough review of their architecture the reasons they highlighted to me are:
Show this thread
1
43
Show this thread
🌤️livier Jacques
@ojacques2
With environment specific configuration files and feature toggles, merging activity between branches is done at a much smaller granularity and thus easier. I can also drastically reduce the chance of code deviation and behaviors being different between shipping targets.
1
1
Show this thread
🌤️livier Jacques
@ojacques2
Regardless how much effort you put in keeping this branching madness under control, merging the changes in those branches with other live branches will always be too late in the cycle. Get ready for surprises.
1
Show this thread
🌤️livier Jacques
@ojacques2
You also do not want to have deviation between all the branches. With Git flow, you can very easily 10s of branches live in parallel - a little bit less with Git branches per shipping target. Keeping them in sync demands a lot of energy.
1
Show this thread
🌤️livier Jacques
@ojacques2
Git branches per shipping target - while slightly less harmful than Git flow - also creates late merging activities. You don't want to have the surprise of having all the code from all developers being put together just before releasing or testing.
1
Show this thread
🌤️livier Jacques
@ojacques2
Start seeing a pattern? Git flow implements an earlier workflow which used to work. But when business demands an increase in frequency of changes / releases, those practices (as well as manual testing) become unsustainable.
1
Show this thread
🌤️livier Jacques
@ojacques2
Yet, developers can be very happy with Git flow as merging activity can be the role of a "release manager/coordinator" whose job is to assemble all the code from all developers and hope for the best. This is not where we are going. But this is also how it worked before.
1
Show this thread
🌤️livier Jacques
@ojacques2
Why is Git flow (still) so popular? The mental model which consists in separating different shipping targets (dev/staging/prod environments, different customers) with a Git branch is very appealing at first.
1
1
Show this thread
🌤️livier Jacques
@ojacques2
Back to the title of the thread: many tech leaders are still advocating for "Git Flow" (aka nvie). While Git flow has since then been challenged by many and specifically by
@adam_ruka
in his famous blog post "GitFlow consider harmful" - 7 years ago.
Animation for Git flow branching strategy which consists of a main branch, a dev branch as well as feature branches and release branches.
GIF
1
2
Show this thread
🌤️livier Jacques
@ojacques2
Second, you will hear me advocate for Trunk Based Development and short lived branches (if any). In my experience, TBD is easily understood by developers, yet a powerful and complete workflow for building, testing, deploying and operating applications and services.
Animation for Git trunk based development, where developers all commit to the same branch. Short lived feature branches can be included too.
GIF
1
Show this thread
🌤️livier Jacques
@ojacques2
As we want to handle "everything as code", Git branching strategy becomes key for how we manage not only application code but also infrastructure, tests, CI and CD, configuration and documentation code.
1
Show this thread
🌤️livier Jacques
@ojacques2
Epyx Winter Games / Summer Games II. Bien que j’ai beaucoup joué à Raid over Moscow et spy vs spy avec mon frère. Uridium était hors catégorie.
Quote Tweet
Benj Edwards
@benjedwards
40 years ago, Commodore released the Commodore 64, which became the best-selling desktop computer of all time As a game console and BASIC machine, it delighted millions. I wrote about it for @howtogeek: howtogeek.com/820304/the-bes What's your favorite Commodore 64 game?
A photo of a Commodore 64 computer on a blue background.
🌤️livier Jacques
@ojacques2
Glad to have contributed a bit to this. Fostering better documentation, one contribution at a time.
Quote Tweet
Nick Frichette - @frichetten@fosstodon.org
@Frichette_n
Thanks to an awesome update to Material for MKDocs (and a little debugging on my end), Hacking the Cloud will now display contributors on each page, along with when a page was created/updated. If you'd like to contribute, your profile picture will be there for all to see 😀
Image
2
🌤️livier Jacques
@ojacques2
Loving the focus on developer experience. Also, the timing is 👌
Quote Tweet
Amazon Web Services
@awscloud
Official
Transform plain ol’ text into lines of code.🪄🐇👨‍💻 Amazon CodeWhisperer uses #MachineLearning to generate code recommendations based on developers’ natural language comments & prior code—reducing app build time. AbraCODEabra, it’s #ML magic. 👉 go.aws/3HPAaJq #AWS
Embedded video
0:08
12.9K views
1