Jekyll2026-02-15T18:55:58+01:00https://islomar.es/feed.xmlLike tears in rain đŸ€–đŸš€Personal blog where I (have the intention to) write about product/software development, Psychology, Anthropology, Buddhism, Lean, eXtreme Programming (XP), DevOps or whatever I feel like 🙏Isidro LĂłpezVertical Slicing Listicle2025-06-08T19:41:41+02:002026-02-15T17:21:41+01:00https://islomar.es/vertical-slicing-listicleEvery time I arrive to a new company or team, one of the first things that I get myself doing is talking about vertical slicing: why it matters, techniques, workshops, etc. And then, I take a look for the n-th time to the resources I have saved in Notion, Drive, GitHub, or my hard-drive (distributed systems have their drawbacks đŸ€Ł), in order to share them (because
 well, you know, sharing is caring 😄).

The goal of this post, which I will update whenever I discover more interesting resources, is to have in a single place the main resources that I have found valuable related with “vertical slicing”. Some people refer to it as story slicing or vertical story slicing: all sounds great to me. Personally, I prefer thinking of “story slicing” as the generic term, where we can find “tastes” like “vertical slicing” or “horizontal slicing”.

As usual: this post is for my future me, but I decided to share it in case it might be found useful for someone else 🙏

Although the goal of this post is not to explain what vertical slicing is and its benefits, I will do a quick and hypersimplified review of it:

What is slicing?

  • I love something I heard during a workshop with Kevin Meadows and Chris Pipito:
    • “Getting to the smallest possible thing we can have a conversation about. ‘What can we do today, that can be used tomorrow?’ That can make tomorrow easier for customers, for users or for us.”
  • Horizontal slicing (PLEASE, AVOID IT 🙃):
    • “A horizontal slice tends to decompose problems into technical layers which may seem to match well with the technical skills of team members, i.e. they’re split amongst a database team, a UI team, and a server team each of which is responsible for their own tasks. Even though we may call these horizontal slices user stories, and create them in form of user stories, they are in fact can’t deliver the value to the end customer without interaction or integration with other layers, components, or other building blocks of the software system. It is like slicing a cake horizontally, which does not allow for users to have the perfect bite.” (source: User Story Splitting - Vertical Slice vs Horizontal Slice)
  • Vertical slicing:
    • Vertical slicing is a technique in agile product and software development where work is broken down into small, end-to-end increments that deliver value across all layers of the system—UI, backend, database, etc. Each “slice” represents a complete, functional piece of the product, allowing teams to build, test, and deliver working software iteratively and get early feedback.
Is this the alt??
(from Gianty )
A cake slice showing several horizontal slices with a cherry on top
(from Visual Paradigm )

Why do we “need” stories?

  • Bridge business-technical communication
  • Focus on user value over tech specs
  • Enable iterative and incremental delivery & feedback
  • Support prioritization (and re-prioritization)
  • Track progress

My personal opinion: in order to enable and get its benefits, you need some principles and practices (e.g. from XP and Lean), e.g. parallel changes techniques, continuous delivery/deployment, deferring commitment, simplicity, a design that enables it (e.g. ports and adapters aka “hexagonal architecture” or some patterns from DDD), etc.

Some techniques and heuristics

Workshops

LLMs

  • Lean GPT
    • Edu Ferro built a Custom GPT to help teams ship smaller, safer, faster. It challenges assumptions, guides toward small safe steps, enables continuous learning and delivery.
    • For developers, PMs, designers, architects—anyone building products.
    • Lean Discovery
    • Lean Delivery
  • Bokata: Vertical Slicing & Task Decomposition Prompt Framework, by Abraham VĂĄllez
    • Bokata is a prompt engineering framework designed to guide Large Language Models (LLMs) in decomposing complex software requirements into incremental, high-value, and actionable development plans.
    • Using techniques like Vertical Slicing and User Story Mapping, Bokata transforms vague ideas or large PRDs into a structured “Walking Skeleton” and a prioritized backlog of functional increments.

Further interesting topics, tools, and techniques

Feel free to suggest other resources that you have found helpful, insightful, or illuminating!! 😊🙏

]]>Isidro LĂłpezQuestions and answers from my talk at the BilboStack 2024 conference2025-03-16T16:26:27+01:002025-03-16T16:26:27+01:00https://islomar.es/questions-and-answers-bilbostack-2024

This is the English version for the post I wrote in March 2024 answering several highly interesting questions related to my talk at the BilboStack conference about Continuous Deployment (including a lot of product-mindset, eXtreme Programming, and Lean Product Development values, principles and practices).

There were questions related with code freezes, branching strategies, teams in distributed timezones, painful experiences with Git Hooks, async PRs, pairing, parallel changes techniques, technical debt, outside-in TDD, how to deal with deployment coupling between front-back, achieving ISO 27001/SOC2 certifications while practicing continuous deployment, etc.

Questions and Answers from My Talk at BilboStack 2024

When at the wonderful BilboStack I finished my talk on Continuous Deployment (I’ll never get tired of repeating that it was just an excuse to talk about “what really matters”, which is the ability to deliver value in a continuous and sustainable way, while enjoying the journey), I was informed that there were no questions đŸ˜±
In my experience, when that happens it means the level of boredom was astronomical and the message didn’t land at all 😅

Luckily, it seems the explanation was less dramatic: there was some problem with the application that collected the questions (was a test missing? 😜). The organizers were kind enough to send them to me afterwards, so I’ll try to answer them in this post.

Important clarification: I lack a lot of context in almost every question; I would need to understand many things better before giving a “reasonable” answer. I’ll make this explicit in some responses and infer it in others 🙏

  1. Can you explain how to achieve ISO 27001/SOC2 while working in continuous delivery?
    • Summary: Not really đŸ€Ł But I can share a few tidbits that might help somewhat

    • One thing I mentioned the other day while talking with someone about this topic is that we tend to take too many things for granted. The very first thing we must always do is to UNDERSTAND in depth the needs to be met. I think there is a lot of “broken telephone” at play and we infer that many things are needed that are actually potential solutions (e.g. having a PR) rather than the underlying need to be solved (e.g. that more than one person has reviewed something).
    • That said: I know that the auditor you get can influence things a lot.
    • At a much higher level, Clarity published a post about this: “ISO27001 and SOC2 Type II from Greenfield to Success”
    • In my team we actually practiced “Continuous Deployment” and in our case it was enough to follow these requirements:
      • Each commit included the Jira issue that originated it – generating an unequivocal trace to the need that gave rise to that code.
      • Since we worked in pairing or ensemble programming by default, every commit included all the people involved by using Git’s “Co-authored-by” feature
        • To reduce friction, we all had a shared git message template with the rest of our team members, so we didn’t have to keep writing it.
        • As far as I know, and simplifying a lot, one of the things required is evidence that someone other than the code’s author has reviewed it. This practice satisfied that need.
      • If the change to be made was “very trivial” (which is always abstract, but we had a document defining it), it was allowed that no reviewer existed (e.g. a change in documentation). In these cases, it was enough to include in the commit message a certain keyword (in our specific case, [trivial-small-change]).
    • For people working with branches and PRs/MRs, the person who validated the PR had to be different from the one who opened it.
    • If you need more detail, perhaps Edu Ferro can tell you more things 🙏
  2. What do you think of code freezes? Do they make sense in certain cases? For example, a large company with teams distributed across different time zones.
    • Questions that come to mind:
      • Are we talking about distributed teams or distributed systems? Or both?
      • When we talk about distributed teams, is it on an individual level or at the team level? Are all members of the same team in very different time zones? Or is the dispersion at the team level? (That is, members of the same team in a similar time zone, but each team in very different time zones)
    • Although I believe everything can make sense in some context, in general “code freezes” (especially if they occur relatively frequently) are a bad symptom. The mere fact of being a large company with teams distributed across different time zones does not imply that those code freezes should exist. Each team should have end-to-end ownership of a “value stream” (see the “stream-aligned teams” of Team Topologies).
    • Here Conway’s Law (and its reverse) comes into play, and one must be very careful with how teams, systems, and their responsibilities are designed.
    • Something that can also help is the existence of “Team APIs”.
    • Depending on the degree of overlapping hours, “core” hours can be set for pairing/ensemble work.
    • If we talk about distributed individuals: a branching strategy like “Ship, Show, Ask” might be interesting.
    • If what we’re discussing is a distributed system and not only distributed teams (which is not the same), then it is essential to perform very good “Contract Testing”: each system/service should be functionally testable in isolation without depending on the rest. This is independent of having additional end-to-end tests (which, in complex distributed systems, becomes quite complicated).
  3. Thanks for the talk! In your opinion, what would be a good branching strategy? Currently, having baby-commits and merging into the main branch, we opt for squash and merge, which creates a new commit and loses the trace of the old commits, leading to a commit hell when reviewing PRs. They usually ask us to try to make a single commit per feature and then merge (not fast-forward) and I manage that with git –amend.
    • My first answer: “it depends” 😜
    • My second answer: the branching strategy that generally allows for fast feedback and a continuous, sustainable value contribution is “Trunk-Based Development”, better with a single default branch (accompanied, as I mentioned in the talk, by pair/ensemble programming, TDD, a secure, repeatable, and powerful pipeline, micro-commits, etc.).
    • Personally, I prioritize the continuous flow and getting the commit to Production as soon as possible over having an “immaculate” commit history. What is always important is that the commits are descriptive and clearly state the “why” above all (“the what” is implicit in the commit).
    • In line with what you mentioned, the good folks at Codely recorded a video a couple of years ago with their opinions on the matter. I think it might interest you if you can’t work with a single branch. I highly recommend it (it’s in Spanish): “Git Merge vs Rebase vs Squash: Which strategy should we choose?”
  4. What are the advantages and disadvantages of having tests in a Git hook?
    • Clarification: Everything you put in Git hooks must be “fast.” What “fast” means depends on the sensitivity of each person or team, but in my experience any execution that exceeds 5 seconds starts to “hurt” (pushes can take a little longer because we run them less frequently, but not much longer). In any case, and in my opinion, it’s better to wait “a little” at the time of commit-push than to face too many “surprises” later (a context switch problem). Also, in my opinion, it is wise to balance what is included in the pre-commit and what in the pre-push (see examples in the diagrams with real cases from the talk).
    • Advantages: You get much faster feedback if tests fail (you don’t have to wait for them to fail in the pipeline when you’ve already switched focus and are halfway through something else). Of course, I wouldn’t include the slower tests, but only the “fast” ones (in my opinion all unit tests should be fast, as well as some integration tests – what I consider “unit” or “integration” could be a post on its own).
    • Disadvantages: The problem arises if their execution is “too slow”; what will eventually happen is that we’ll skip them or accumulate too many changes. The solution is to have only the fastest tests or those that do not cause too much slowdown in the Git hooks. Parallelizing their execution as much as possible is important to reduce times.
  5. At first glance, very interesting. As a question: didn’t you notice that pre-commit and pre-push hooks could add friction and latency in the commit process, leading the team to make larger commits to avoid running linting, tests, etc. multiple times?
    • Very good question, and unfortunately it is not uncommon for that to happen. One must be very alert about it. I tried to address it in the previous question â˜ïžđŸ™
  6. Synchronous validations or asynchronous PR validations?
    • I’m not sure if I understand this question, sorry. What do you mean by “validations”? Are we talking about tests? Linters? Or code review?
    • In line with what I mentioned in the talk: we must try to get feedback as fast and as frequently as possible for everything. As much as possible, I would prioritize synchronous code reviews; and even better: do as much pairing/ensemble work as possible.
    • I would also recommend taking a look at the branching strategy “Ship, Show, Ask”, which might be interesting as a step toward reducing integration times.
  7. When the “vicious cycle” you showed at the beginning becomes so large, how do you get out of it?
    • Uuufffff, a difficult question (or rather, a difficult answer 😅). The first necessary step is to have a general awareness of the problem and its nature (I would say that this is the hardest part). Making it visible and explicit, with data, always helps (for example, measuring the time from the moment we make a commit until it reaches Production), putting it in black and white.
    • The next important step is to really want to invest time in solving it, to clearly see the benefit that solving it can bring (which again is very difficult if it hasn’t been experienced before).
    • If all of the above is met: take it slowly. First, identify any “quick wins” that may exist (low cost and high benefit). Improve automated testing. Gradually reduce branch/PR times as much as possible. Adopt branching strategies that decrease the time it takes to integrate into the main branch. Increase and improve collaboration (e.g., through pairing). Learn techniques for parallel changes and start using “feature flags.”
  8. How can you showcase the contribution of CI/CD and overcome developers’ fear of deploying things early?
    • In my experience, the best way I’ve seen is to lead by example (which requires experience doing so), while also providing a lot of education about the value it brings to everyone, both business and engineering. I don’t think there are shortcuts or magic formulas
 😕 Of course, that “deploying things early” must be accompanied by a robust safety net; otherwise, the remedy will be worse than the disease, and understandably people won’t want to do it.
  9. Do you use pairing strategies like ping-pong? In these cases, wouldn’t the use of Git hooks be annoying?
    • In the past, I have done pairing with TDD using ping-pong (I’d say I have done pairing in almost every possible mode đŸ€Ł).
    • When I did ping-pong (Person A writes the test, Person B makes it pass, refactors, then Person B writes the next test, etc.) we did it by sharing the terminal (that is, both people really worked on the same machine, using tmate). This implies that we did not commit until the test was green (and therefore Git hooks were not a problem).
    • One thing I would never do, regardless of Git hooks, is push code to the main branch without tests.
    • There are people who use this tool which might cover certain use cases (personally, I prefer not doing ping-pong and simply rotate by pomodoro, which is enough).
    • On the topic of pairing, this post is really good: On Pair Programming
  10. Can having too many micro-commits get the main branch “dirty”?
    • It depends on what is meant by “dirty”. What is always important is that commits have good messages, clearly describing the “why,” and of course no commit should break the tests.
    • That said, I believe it is more important to take small steps and have continuous feedback and flow than to maintain a supposedly “ideal” commit history.
  11. Generally, it is required that a feature be complete before being pushed and they don’t want to see anything until it’s finished. Would trunk-based development be applicable?
    • Absolutely. To resolve the problem you describe, which is very common, there are multiple techniques for parallel changes (I included some information on this) and, above all, the use of feature flags/toggles.
    • This is related to the decoupling I mentioned during the talk between “Deployment” (a technical decision) and “Release” (a business decision).
  12. For using CD with trunk-based development, when making commits and pushing them, did you have any configuration to prevent commits that don’t pass tests?
  13. To the question someone asked: “It’s to change the world, because to a greater or lesser extent when we push a change, it changes the lives of some people (for better or for worse) – our users or clients, because they have tools to do their work better.”
    • I understand this is the answer to the question I posed: “Why do we develop software professionally?” I find this perspective wonderful, truly—I feel very aligned with the idea underlying it.
    • Regarding the nuance I mentioned in my answer that I wanted to highlight, I would say: what if you could change/improve the world more optimally/efficiently WITHOUT software—wouldn’t you do it? 😉
  14. Do you think it makes sense to run several CI processes in parallel? For example, unit tests, building the build, and e2e tests at the same time?
    • Yes, but it depends on which ones. Without a doubt, we must parallelize everything possible, starting with the tests themselves (almost all testing libraries allow parallel execution); additionally, it forces us to write “self-contained” tests whose input or output does not depend on other tests (which is by default what is most recommended). There should be no issue with unit and integration tests. With e2e/acceptance tests it might be different (it’s worth differentiating which ones can be parallelized and doing so).
    • In the two real-life examples I included you can see what we parallelized and what we didn’t; I’d say almost everything was done with great awareness (and always improvable) 😊
    • For example, regarding the second pipeline, I can explain why we didn’t parallelize those three tasks in particular:
      • We did not want to invest time in building the Docker image (and subsequently pushing it to an ECR) if the tests didn’t pass first.
      • Unit tests are the fastest and the most blocking: we don’t want to do anything else if they fail (another reason not to parallelize them with some other tasks). We can parallelize them with other equally fast tasks, such as linters and other static validations.
      • As for e2e tests: in our testing taxonomy, these are tests we run against the new version of the system already deployed somewhere (staging or production), so we couldn’t parallelize them with the build or unit tests either.
      • The tests we did parallelize as the first step in the pipeline were the unit tests (which follow the FIRST principles), integration tests (in our case tests for the secondary adapters of our hexagonal architecture), and acceptance tests (which are tests “from the outside” run against the system that includes the updates, brought up “locally” before being deployed).
  15. When doing TDD outside-in, you first write tests from the user’s perspective but then, do you continue with more internal tests?
    • Exactly, that’s the idea. It’s similar to Acceptance TDD, Specification by Example, or Behaviour-Driven Development (BDD) (there are nuances among the three, but in all cases we seek to test the system’s behavior from the perspective of its external user).
    • I would say that perhaps it is not always possible (I don’t always manage it), but it should be the primary approach: when done that way, the development experience is fantastic (and of course so is the user experience) 😍
  16. Do you consider it indispensable that continuous delivery always goes all the way to production? Wouldn’t it be enough with a Test environment that is a replica of Production to avoid risks?
    • We must not confuse “Continuous Delivery” with “Continuous Deployment.” In the first part of my talk I tried to explain the differences.
    • With “Continuous Delivery”, indeed the pipeline does not deploy to Production. It may, for example, stop at a pre-production environment (e.g. Staging). The important thing is that once our code is integrated into the main branch and the build and automated tests have run, it remains in a “deployable state”: whenever we want, we could deploy it to Production (and that deployment should be simple and repeatable).
    • With “Continuous Deployment”, on the other hand, the entire pipeline is completely automated, including the step of deploying to Production.
    • In the first pipeline example I mentioned, we had Continuous Deployment but we still deployed first to a Staging environment: after deploying there, several e2e and smoke tests ran automatically and, if everything worked correctly, it was automatically deployed to Production.
  17. Understanding that a release is a business concept rather than a technological one, why is taking product delivery lead time as a metric important? Isn’t that something outside of technology’s control?
    • Good question. My answer: because it is fundamental to see it as a “whole.” From the perspective of engineering/technology, we must understand that technology is a means to an end.
    • To me, it is one of the keys to evolving toward “product engineering”: understanding that ALL of us are part of the product and the business, and that what we do must meet user needs.
    • In reality, from an engineering perspective we can and should influence the “product delivery lead time” much more than we think. I have often seen product managers’ vision change (for the better) when developers bring to the table simpler ways to start satisfying user needs.
    • Obviously, the appropriate company culture is needed for this to occur so that we do not end up with isolated silos where “business” and “technology” are completely separated: we must move toward understanding that we are all the PRODUCT and need to collaborate continuously and intensively.
  18. When always working on the same branch, if you push to the server and something fails, as part of that rollback is a commit with a revert automatically generated? Or would the main branch be blocked?
    • First, let’s do what we can in each context, which is already a lot 😄
    • In the second real-world example that I shared in the talk, it was a very quick rollback of the deployment, so no commit was generated. To give more technical details, we did the rollback with helm (which was also what we used for deployment).
    • When that happened, we received a message in the team Slack channel for important issues (e.g. any pipeline failure).
    • The automatic rollback in Production gave us the peace of mind of knowing that the system remained in a stable state, with the previous version still functioning.
    • Once we finished the pomodoro that was in progress (we primarily work in ensemble), we immediately prioritized checking what had failed and resolving it. There was no “blockage” of the main branch because we worked in ensemble. But if that were not the case—as I mentioned in the talk—fixing a broken pipeline must be PRIORITY, meaning it isn’t that the branch stays blocked; it must be fixed immediately, and everyone on the team, regardless of who made the commit that broke it, works together (I believe that a change in mindset is important, and working in isolation and very individually doesn’t help).
    • Working in a single branch with lead times of minutes, there was no need for the concept of a “hot fix”: after the automatic rollback, we fixed the issue as soon as possible (within a few minutes) and committed the fix (with an automated test included to avoid recurrence, if possible) and then moved on 😉
    • Part of the philosophy here is that when there is an incident in Production, the first and most important thing is to get Production back up and running as soon as possible—whether by reverting to the previous version or by quickly committing a solution.
    • Over two years, there have been very few occasions when such a rollback occurred (we had a very strong safety net in place). We must not get used to it happening all the time; that would be a symptom of needing to invest in improving the safety net.
  19. Thanks for the great talk, you rock! I love your point about discipline and especially about the bottleneck focused on knowledge! I have a question: This world has evolved with terms like CI/CD and others such as DevOps, DevSecOps. What do you think about this? Who should have this responsibility, an individual or a team? I’d love to know your perspective.
    • Thanks! Well, in my opinion with DevOps we have reached a situation of “semantic inversion”: it ended up meaning exactly the opposite of what was intended. The goal was to improve collaboration and break down silos of knowledge, blockers, and hot potato handoffs, but in general it ended up with “DevOps teams” (essentially a renaming of the “systems team”) that continue to maintain silos, blocking dependencies, etc. </rant>
    • DevOps is a culture, not a team. This is not incompatible with having, for example, platform or enabler teams that make life easier for the “stream-aligned teams” through various self-service tools and services. But teams—say, “external product teams”—should not have blocking dependencies on those teams.
    • The same applies to DevSecOps: as much as possible it should be integrated into the deployment/delivery pipeline, probably supported by services/tools from other teams.
  20. Do you think the trunk/CI approach is valid for addressing technical debt or for sustaining tasks like upgrading versions of frameworks or libraries? Or is it something exclusive to product delivery?
    • Absolutely, I believe that TBD/CI can be applied in multiple contexts.
    • In fact, I think the best way to address technical debt (which, by the way, we need to be sure we are talking about the same thing 😄) is gradually. Running “technical debt sprints” is usually a symptom of a lack of “slack” in the team (among other things).
    • Regarding framework/library updates: here I’d say it depends.
      • For library updates, I’d say yes (in my team we used renovatebot to automatically update all libraries on a daily basis, and the pipeline still deployed at the end). But again, I repeat: you need a very robust safety net, especially very good automated tests.
      • As for framework updates: it depends on the implications of the change. Normally yes, but when they are major versions, it is not unlikely that the impact is significant enough to require doing it in a branch that lives for more than 24 hours so you can change and test everything calmly.
  21. Do you have any suggestions or techniques for running E2E tests in Production? For example, synthetic traffic, traffic mirroring, etc.?
    • Interesting question 😄 The answer is: “it depends on the context” (sorry, not sorry). To share a couple of very different cases I’ve encountered (among many others):
      • At Clarity AI:
        • See the second real-life pipeline example that I shared.
        • There we had several e2e tests (those that mimic a real user): some using Cypress (the main service was a Slack app (with a slash command), so these tests actually accessed Slack from a browser and executed various commands) and some in pure Python (making HTTP requests to some endpoints that we also published).
        • The services/applications deployed there were all for internal use by Clarity employees (about 300 at the time), mainly in Engineering.
        • For all the above, in our specific case scalability wasn’t an issue: we didn’t have hundreds, thousands, or millions of concurrent users. Therefore, we didn’t need load or stress tests, and the e2e tests we had didn’t require anything special.
      • At Form3:
        • Here things change: for several months I was on the (micro) scalability team, whose main responsibility was detecting (and sometimes fixing) bottlenecks in the scalability of our (not simple) distributed system.
        • To say that Form3’s product was (or is) an HTTP API in fintech is an understatement. We handled a lot of money daily and it was quite critical (no one died, but it was no laughing matter đŸ€Ł).
        • Something very interesting is that we worked hand in hand with the Sales team to generate simulated traffic based on the “real” forecast of new users (e.g., if X contracts had been signed for a certain date, implying N new clients/users).
        • The load and stress e2e tests were run with k6.io (in fact, Form3 eventually released an open-source solution called ‘f1’ that simplified this based on the work we did on my team; it’s very interesting, I recommend checking it out). We created an hourly distribution of requests similar to what we usually had, with Gaussian distributions but with the estimated volumes.
        • It’s something that, honestly, I had not seen done before, nor have I seen it done again đŸ€Ż
  22. How can you balance huge test suites that slow down pipelines with the speed required in trunk-based development?
    • To clarify, in Trunk-Based Development (TBD) or CI that “speed” isn’t as critical in my opinion – at least merging once a day into the main branch. I’d say the more frequent, the better: for example, every 2 hours is preferable to every 24 hours; and if you can work with a single branch by default and merge every few minutes, that’s icing on the cake (in my experience, the difference is enormous, but life is tough and we do what we can
).
    • Those “huge test suites” you mention – what exactly makes them so huge? Is it a large non-modularized monolith? Or is it because there are “too many” slow tests?
    • As I mentioned above: we must parallelize everything we can. Most of our tests (regardless of type, even integration and e2e) should be parallelizable (by default, with few exceptions, they should initialize what they need autonomously and then restore everything as it was).
    • With proper modularization, perhaps only the tests that give us enough confidence for deployment could be run (only triggering the affected ones, using “contract testing,” only the most critical e2e/functional/acceptance tests, etc.).
    • And finally: it is advisable to have many more fast tests than slow ones.
  23. I have mixed feelings about pre-push and pre-commit hooks, as I’ve seen that sometimes they lead developers to make larger commits than they should in order to avoid running linting, tests, etc. multiple times. I wanted to ask your opinion about that – if you have experienced it and, if so, how did you channel the situation. [Question received via Twitter, thanks Eneko 🙏]
    • First, I’d need to understand why linting, tests, etc. fail multiple times. Is it because there are flaky tests or some type of non-deterministic validation? Or is it simply because developers “make mistakes”?
    • I haven’t encountered the situation you describe, perhaps because there are several aspects on which I always place high priority with Git hooks:
      • They must be VERY fast. Otherwise, one will be tempted to skip them or wait until you have many changes to run them.
      • They must be deterministic: the result should not vary if the “input” (tests, linters, whatever) hasn’t changed.
      • We normally practice TDD, so if a test fails, we usually find out sooner rather than later (shortening the feedback loop).
      • We have linters and formatters configured in the IDE exactly as they are in the Git hooks. This usually provides even faster feedback and almost no surprises when Git hooks run.
    • And
 basically that’s all I can think of 😅 As I said, I’d need to experience the situation in person to fully understand where the friction is 😊🙏
  24. Doesn’t the possibility of doing Continuous Deployment go hand in hand with the criticality of potential application errors? That is, it is not the same to introduce a bug in, for example, a music streaming platform as in a financial transactions app or one that handles very sensitive data.
    • In my opinion, no 😊 The main motivation for “Continuous X” (Integration/Delivery/Deployment), as I mentioned in the talk (sorry for the self-reference), is to LEARN quickly (so that we can adapt and reorient ourselves fast and deliver value quickly). We want feedback as soon as possible about both WHAT (user/client/business needs) and HOW (systems/technology/organization). And generally, we want that all the time; in fact, it seems to me that in the example you mention (and in my experience) it probably applies more in the music app than in the financial one.
    • As I see it, the reasoning is actually the opposite: it is to enable that continuous learning, those rapid feedback loops, for which we need, among other things, a very strong safety net that will result in fewer application errors. Reducing bugs is not an end in itself; it is a means to other ends (improving user experience, delivering value, continuous learning, etc.).
    • In other words: in the false dichotomy of “quality vs. speed,” only with good internal quality can we achieve speed.
  25. It seems we try to reinvent the wheel but always end up coming back to Eliyahu Goldratt’s concepts. In what cases do you think we should NOT apply all these principles? Or conversely, do you consider them universal for any problem space?
    • Uuffff
 a difficult question. In summary: no, I don’t think they are universal for every problem space. For example, if you have a pure, hard CRUD where you “know” it will hardly evolve (something I’ve almost never encountered, but let’s imagine), then I wouldn’t apply them. There is no uncertainty (or so we believe), nothing significant to learn. But more importantly: in that context today I wouldn’t even develop software, as there are plenty of NoCode tools to resolve such cases (e.g., when business domain logic is minimal).
    • If I were to act as a “coach” 😜, I’d talk about the Cynefin framework and that in the “clear” domain, everything is already sold.
    • That said, I believe that statistically (at least based on my anecdotal evidence) this context is infinitesimal; it is not the usual context in which we operate and for which we are paid.
  26. When, due to the context of initiatives (e.g., very complex changes), you cannot merge daily, can it still be considered Continuous Integration?
    • First, I’d need to understand that context much better.
    • Here I will “challenge” it: in most cases where someone or a team has indicated that their context was “special” or “too complex” and therefore they couldn’t do X or Y, when I’ve dug deeper, asked questions, and tried to understand, I (or we) found that the underlying problems were different and that it was actually possible to do it (or at least start moving in that direction). I’m not saying it’s your case, because I lack a lot of information, but I do say that almost always it is possible.
    • In very sporadic cases, anything goes – we are human and that’s what happens (and indeed there are specific situations where there is no alternative). But if that is the everyday situation, if you really can’t merge daily into a main branch for your regular work, I find it hard to believe that it isn’t a matter of knowledge, principles, and practices (i.e., a self-generated problem). It is probably “accidental complexity” rather than “essential complexity” (see the famous “No Silver Bullet” by Fred Brooks).
    • In any case: if you aren’t merging at least daily, I don’t think we can talk about “continuity” (and it’s not about linguistic purism, but about the value of the practice).
  27. How would the process be for deploying front-end features that depend on back-end changes using TBD?
    • To use a clichĂ©: I’m glad you asked that question đŸ€Ł. In fact, during the networking session someone asked me the same case (perhaps it was the same person).
    • Disclaimer: It is highly recommended that an entire value stream be handled within the same team. There are always exceptions, but as a general rule both the Front and Back for an end-to-end feature should be the responsibility of the same team.
    • On one hand, I must again mention the importance of using feature flags to enable various changes in parallel. For example, for this specific case, we could have a feature flag both on the Front and the Back (with the same default for both), so that either part can be continuously deployed without impact for the users, while progress is made gradually or while waiting for the “other part.” The idea is to hide from the user what is not yet functioning correctly because it is still under development.
    • At this point, I’d like to share a concrete experience that I find very relevant for this case: the project we worked on at Codium for a client, from which I showed one of the Continuous Deployment pipelines we had (specifically, the back-end one).
      • Important context:
        • We formed a mixed team of 3 people from Codium and 3 from the client (one of them acting as “Product Manager”). We worked in pairing and ensemble programming by default. And although one person was more specialized in Front and another in Back, the rest rotated between both worlds: there were hardly any silos or isolated compartments—in the team almost everyone did almost everything (each with their own strengths, of course). We were also very autonomous in the Systems part.
        • There was a Back-end (in PHP, with Symfony) and a Front-end (React with TypeScript). The Back published an HTTP API that the Front consumed.
      • Bottom line: we used OpenAPI to define the contract to be met between Front and Back. When a new behavior (or change) was required that implied changes on both sides, the first thing we did was to gather the entire team to write the “contract” together. In a YAML file, OpenAPI allows you to define that contract – e.g., the endpoint URI, input types, output types, HTTP status codes returned, etc.
      • Once we had this contract written by everyone, we could, if we wanted, tackle the Front and Back separately. Depending on the type of change, sometimes not even a “feature flag” was needed.
      • To ensure that neither side broke the contract, we had several validations in Git hooks and in the pipeline (as you can see in the diagram I shared):
        • Back-end:
          • We used schemathesis. It is a tool that automates testing of HTTP APIs by dynamically generating test cases from the OpenAPI contract. It allows multiple configurations depending on the number of tests desired, parallelism, etc.
          • Basically, we used it to run dynamic tests based on the contract against the API published by the Back.
          • We ran it at two different moments:
            • In the pre-push Git hook, against a local environment (automatically brought up with Docker).
            • During the pipeline, for example against the Staging environment, once the Back was deployed there.
        • Front-end:
          • We used jormaechea/open-api-mocker, which is an API mocker based on OpenAPI 3.0.
          • It essentially spun up a mock server based on the OpenAPI contract, which received requests during certain types of Front-end tests.
        • The YAML file with the OpenAPI contract was present in both the Front and Back: this duplication wasn’t ideal, but it was very “cheap” at the time. In the pipeline, we had a validation to ensure that the contract was exactly the same on both sides (and, of course, we would immediately notice if it wasn’t).
      • IMPORTANT: The choice of these tools was made several years ago; it is very likely that better solutions exist today 😊
      • If the Back endpoints were consumed by many more consumers (excuse the redundancy), perhaps we could consider more advanced (and much more complex, better to wait until it’s REALLY needed) solutions like Pact.

And that’s it!! With this, I finally scratch the itch of not having been able to answer any questions after my talk 😊

I truly had a lot of fun answering these—it was an interesting exercise, and I only hope I’ve provided something valuable to someone 🙏

]]>Isidro LópezMy ethical stance2024-03-17T12:35:00+01:002025-06-05T22:11:27+02:00https://islomar.es/my-ethical-stanceIMPORTANT DISCLAIMER: I’m writing this post as a personal reminder, not to tell anyone what they should do, convince anybody of anything, impart moral lessons or grant any kind of “licenses”. Life is hard and I have enough on my plate with setting my own moral compass 🙏

I’m currently in a “relaxed” search of new professional challenges. By “relaxed” I mean that I have not openly published it and I’m not intensively searching: for the moment, I just knocked a couple of doors (from people/companies I feel a high level of alignment) and entered a few processes with people who directly approached me (I’m such a privileged person and I feel SO LUCKY 😍).

Still, this is a moment when I’m asking myself questions such as:

  • What kind of industries do I feel specially motivated to join?
  • What kind of industries or business models or organizational behaviour I don’t want to join?
  • What are my “ethical red lines”? How big is the “grey area” to me?

This is not the first time that I pose myself this kind of questions. I remembered that Edu Ferro (a reference to me in so many ways) has his own “ethical stance” published here, so I thought it would be a perfect moment to write down mine. And I want to be so specific as possible; otherwise it would be useless for myself.

For different reasons (i.e. there are higher and lower levels of “criticality” in this list) and with no particular order and without this being an exhaustive list, I prefer not to work in:

  • Fast fashion (and anything directly related)
  • Traditional banks (especially those with proven record of abuses and illegalities)
  • “Buy now, pay later” or any kind of “fast credit” business models
  • Porn industry
  • Military industry
  • Any company directly or indirectly connected with any genocidal state (e.g. Israel)
  • Casinos, gambling and bets (“been there, done that”)
  • Any green-washing, or generally speaking, “ethical-washing” activity
  • Crypto businesses and alike
  • Activities where people can quickly lose a lot of money
  • Delivery riders business models that often exploit riders, typically misclassified as “independent contractors”
  • Business models whose main goal is encouraging wild consumerism of any kind
  • Highly polluting activities
  • Anything where there is no full transparency about the business model and how they earn money
  • Any activity without “full honesty”: lying, cheating, hiding relevant information or “tricking” their users, providers, employees, etc.

And I write these words being fully conscious about my own incoherences: with the current complexity of the world and society, I don’t think that it’s possible to live on it being “fully coherent”. Sometimes I would even say that it isn’t “healthy”. Long life to the cognitive dissonances! 😆

Despite my efforts to minimize it, I’m acutely aware of being part of a global community that continuously exploits other regions and people. Shame on me. Shame on us.

Regarding some topics, my views have evolved in the past, and I hope they will continue to do so in the future. Still, I’m not always in peace with that, which I think is good 🙏

]]>Isidro LĂłpezPreguntas y respuestas de mi charla en la BilboStack 20242024-01-31T16:26:27+01:002024-02-04T08:26:27+01:00https://islomar.es/preguntas-y-respuestas-bilbostack-2024

Here you can read the post in English

Cuando en la pasada y maravillosa BilboStack finalicĂ© mi charla sobre Continuous Deployment (no me cansarĂ© de repetir que como excusa para hablar de “lo importante”), me hicieron saber que no habĂ­a ninguna pregunta đŸ˜± En mi experiencia, cuando eso pasa, es que el nivel de turra ha sido astronĂłmico y el mensaje no ha llegado de ninguna manera 😅

Por suerte, parece ser que la explicaciĂłn era menos dramĂĄtica: hubo algĂșn problema con la aplicaciĂłn que recogĂ­a las preguntas (ÂżfaltarĂ­a algĂșn test? 😜). La organizaciĂłn ha tenido el detallazo de enviĂĄrmelas a posteriori, asĂ­ que intentarĂ© contestarlas en este post.

AclaraciĂłn importante: me falta muchĂ­simo contexto en casi todas las preguntas; necesitarĂ­a entender mejor muchĂ­simas cosas antes de dar una respuesta “razonable”. Lo harĂ© explĂ­cito en las respuestas de algunas pero lo inferirĂ© en otras 🙏

  1. ÂżPuedes explicar cĂłmo conseguir la ISO 27001/SOC2 trabajando en continuos delivery?
    • Resumen: realmente no đŸ€Ł Pero puedo compartir algunas cosillas que tal vez ayude en algo

    • Algo que comentaba el otro dĂ­a hablando con otra persona sobre este tema es que tendemos a dar por hecho demasiadas cosas. Lo primero que siempre debemos hacer es ENTENDER en profundidad las necesidades a satisfacer. Creo que hay mucho “telĂ©fono escacharrao” e inferimos que se necesitan muchas cosas que en realidad son una posible soluciĂłn (e.g. que haya una PR) en lugar de la necesidad de base a resolver (e.g. que mĂĄs de una persona haya revisado algo).
    • Dicho esto: tengo claro que el auditor que te toque puede influir muchĂ­simo.
    • A mucho mĂĄs alto nivel, Clarity publicĂł un post al respecto: “ISO27001 and SOC2 Type II from Greenfield to Success”
    • En mi equipo hacĂ­amos de hecho “Continuous Deployment” y en nuestro caso era suficiente con seguir los siguientes requisitos:
      • Cada commit incluĂ­a el issue de Jira que lo originaba: se generaba una traza inequĂ­voca con la necesidad de la que surgĂ­a ese cĂłdigo.
      • Puesto que trabajĂĄbamos en pairing o ensemble por defecto, en cada commit incluĂ­amos a todas las personas involucradas usando el “Co-authored-by” de Git
        • Para reducir la fricciĂłn, todos tenĂ­amos un template del git message compartido con el resto de compañeras del equipo, no tenĂ­amos que estar escribiĂ©ndolo conitnuamente.
        • Hasta donde sĂ©, y simplificando mucho, una de las cosas que se requiere es evidencia de que una persona diferente a quien escribiĂł el cĂłdigo, lo ha revisado. Esta prĂĄctica satisfacĂ­a esa necesidad.
      • Si el cambio a realizar era “muy trivial” (lo cual siempre es abstracto, pero tenĂ­amos un documento definiĂ©ndolo), se permitĂ­a que no hubiera un revisor (e.g. cambio en documentaciĂłn). En estos casos, era suficiente con incluir en el mensaje del commit cierta palabra clave (en nuestro caso concreto, [trivial-small-change])
    • Para la gente que trabajaba con ramas y PRs, la persona que validaba la PR debĂ­a ser diferente a la persona que la habĂ­a abierto.
    • Si necesitas mĂĄs detalle, probablemente Edu Ferro pueda contarte mĂĄs cosas 🙏
  2. ¿Qué opinas de los code freeze? ¿Tienen sentido en determinados casos? Por ejemplo, una empresa grande con equipos distribuidos en distintas zonas horarias
    • Preguntas que me surgen:
      • ÂżHablamos de equipos distribuidos o de sistemas distribuidos? ÂżO de ambas cosas?
      • Cuando hablamos de equipos distribuidos, Âża nivel individual o de equipo? ÂżEstĂĄn todos los miembros de un mismo equipo en zonas horarias muy diferentes? ÂżO la dispersiĂłn era a nivel de equipo? (es decir, miembros de un mismo equipo en zona horaria similar, pero cada equipo en zonas horarias muy diferentes)
    • Si bien creo que todo puede tener sentido en algĂșn contexto, en general los “code freeze” (sobre todo si ocurren con relativa frecuencia) son un mal sĂ­ntoma. El mero hecho de ser una empresa grande con equipos distribuidos en distintas zonas horarias no implica que deban existir esos “code freeze”. Cada equipo deberĂ­a tener el ownership e2e de un “value stream” (ver los “stream-aligned teams” de Team Topologies).
    • AquĂ­ entra en juego y hay que tener mucho cuidado con la ley de Conway y su reverso, cĂłmo estĂĄn diseñados los equipos, los sistemas y sus responsabilidades.
    • Algo que tambiĂ©n puede ayudar es la existencia de “Team APIs”.
    • SegĂșn el nivel de solapamiento horario, se pueden poner unas horas “core” para el pairing/ensemble.
    • Si hablamos de personas distribuidas: una estrategia de branching tipo “Ship, Show, Ask” puede ser interesante.
    • Si de lo que hablamos es de un sistema distribuido y no sĂłlo equipos distribuidos (que no es lo mismo), entonces es fundamental hacer muy buen “Contract Testing”: cada sistema/servicio deberĂ­a poder ser testeado funcionalmente de forma “aislada” sin depender del resto de servicios. Esto es independiente de tener algĂșn tipo de tests end-to-end adicionales (lo cual en sistemas complejos distribuidos se complica bastante).
  3. ÂĄGracias por la charla! ÂżCuĂĄl serĂ­a en tu opinion una buena estrategia de ramas? Actualmente al tener baby-commits y al mergear con la rama principal optamos por squash and merge, que crea un nuevo cĂłdigo de commit y se pierde el rastro de los antiguos commits entrando en un infierno de commits a la hora de revisar PRs. Nos suelen pedir intentar hacer un solo commit por desarrollo y luego mergeo (not fast foward) y yo consigo eso con git -ammend
    • Mi primera respuesta: “depende” 😜
    • Mi segunda respuesta: la estrategia de ramas que, en general, mejor permite tener feedback rĂĄpido y un aporte de valor continuo y sostenible es “Trunk-Based Development” con una Ășnica rama por defecto (acompañado, como comentaba en la charla, de pair/ensemble programming, TDD, una pipeline segura, repetible y potente, micro-commits, etc.)
    • Personalmente priorizo el flow continuo y llevar cuanto antes el commit a ProducciĂłn, que un histĂłrico “impoluto” de commits. Lo que sĂ­ es siempre importante es que los commits sean descriptivos y cuenten claramente “el porquĂ©â€ ante todo (“el quĂ©â€ estĂĄ implĂ­cito en el commit).
    • En la lĂ­nea de lo que comentas, la buena gente de Codely grabĂł hace un par de años un vĂ­deo con sus opiniones al respecto, creo que te podrĂ­a interesar en caso de que no puedas trabajar con una rama Ășnica, te lo recomiendo: “Git Merge vs Rebase vs Squash ÂżQuĂ© estrategia debemos elegir?”
  4. ÂżVentajas y desventajas de tener los test en un git hook?
    • AclaraciĂłn: todo lo que se meta en Git hooks debe ser “rĂĄpido”. QuĂ© significa “rĂĄpido” depende de la sensibilidad de cada persona o equipo, pero en mi experiencia, toda ejecuciĂłn que supere los 5 segundos empieza a “doler” (los “push” pueden tardar algo mĂĄs porque los solemos ejecutar con menos frecuencia, pero no mucho mĂĄs). En cualquier caso, y en mi opiniĂłn, es mejor tener que esperar “un poco” en el momento del commit-push que encontrarnos con demasiadas “sorpresas” mĂĄs tarde (problema de “context switch”). Y por otra parte, es conveniente balancear quĂ© se incluye en el pre-commit y quĂ© en el pre-push (ver ejemplos en los diagramas con ejemplos reales de la charla)
    • Ventajas: tener feedback mucho mĂĄs rĂĄpido si fallan los tests (no tener que esperar a que fallen en la pipeline, cuando ya hemos cambiado el foco y estamos a medias de otra cosa). Por supuesto no incluirĂ­a los tests mĂĄs “lentos”, pero sĂ­ los “rĂĄpidos” (en mi opiniĂłn todos los unitarios deberĂ­an serlo, asĂ­ como algunos de integraciĂłn - quĂ© considero “unitario” o “integraciĂłn” da para otro post).
    • Inconvenientes: el inconveniente surge si su ejecuciĂłn es “demasiado lenta”; lo que acabarĂĄ pasando es que los saltaremos o acumularemos demasiados cambios. La soluciĂłn pasa por tener en los Git hooks Ășnicamente los tests mĂĄs rĂĄpidos o que no provoquen demasiada sensaciĂłn de ralentizaciĂłn. Paralelizar todo lo posible su ejecuciĂłn es importante para disminuir los tiempos.

  5. De primeras, muy interesante. Como pregunta ¿no notaste que los hooks pre-commit y pre-push podian añadir friccion y latencia en el proceso de commit, llevando al equipo a hacer commits mas grandes para evitar hacer menos commits por pasar menos procesos?
    Muy buena pregunta, y por desgracia no es difĂ­cil que ocurra, hay que estar muy pendiente de ello. Lo he intentado contestar en la pregunta anterior â˜ïžđŸ™

  6. ÂżValidaciones sincronas o PR en asincrono?
    • No sĂ© si entiendo esta pregunta, lo siento. ÂżQuĂ© quieren decir “validaciones”? ÂżHablamos de los tests? ÂżDe linters? ÂżO de la revisiĂłn de cĂłdigo?
    • En la lĂ­nea de lo que comentĂ© en la charla: debemos intentar tener feedback los mĂĄs rĂĄpido y frecuente posible de todo. En la medida de lo posible, priorizarĂ­a las revisiones de cĂłdigo sĂ­ncronas; y aĂșn mejor: hacer pairing/ensemble todo lo “posible”.
    • TambiĂ©n recomendarĂ­a echar un vistazo a la estrategia de branching “Ship, Show, Ask”, puede ser interesante como avance hacia la reducciĂłn de tiempos de integraciĂłn.
  7. Cuando el “circulo vicioso” que has enseñado al principio se ha hecho tan grande, ÂżcĂłmo sales de ahĂ­?
    • Uuufffff, difĂ­cil pregunta (o mejor dicho, difĂ­cil respuesta 😅). Lo primero necesario es tener consciencia general del problema y de su naturaleza (yo dirĂ­a que esto es lo mĂĄs difĂ­cil). Hacerlo visible y explĂ­cito, con datos, siempre ayuda (e.g. tomar tiempos de todo lo que ocurre desde que hacemos un commit hasta que llega a ProducciĂłn), ponerlo negro sobre blanco.
    • Lo siguiente importante es querer realmente invertir tiempo para resolverlo, ver claramente el beneficio que eso puede reportar (lo cual de nuevo suele ser muy difĂ­cil si no se ha experimentado antes).
    • Si se cumple todo lo anterior: ir poquito a poco. Identificar primero los “quick wins” que puedan existir (bajo coste y alto beneficio). Mejorar el testing automatizado. Ir disminuyendo todo lo posible los tiempos de nuestras ramas/PRs. Adoptar estrategias de branching que disminuya el tiempo que tardamos en integrar en la rama principal. Aumentar y mejorar la colaboraciĂłn (e.g. a travĂ©s del pairing). Aprender tĂ©cnicas de cambios paralelos y empezar a usar “feature flags”.
    • Y creo que el mejor consejo: buscad y contratad a alguien con experiencia en todo lo anterior, es extramadamente difĂ­cil si no (no digo que no sea posible, pero sĂ­ muy complicado).

  8. ÂżComo se puede poner en valor el aporte de CI/CD y hacer perder el miedo a desarrolladorxs de desplegar pronto cosas?
    Yo como mejor lo he visto hacer es liderando con el ejemplo (lo cual requiere experiencia haciĂ©ndolo), haciendo al mismo tiempo mucha pedagogĂ­a al respecto (sobre el valor que aporta a todes, tanto negocio como ingenierĂ­a). No creo que haya atajos ni fĂłrmulas mĂĄgicas
 😕 Por supuesto, ese “desplegar pronto cosas” debe ir acompañado de una red de seguridad potente, si no serĂĄ peor el remedio que la enfermedad y la gente, con razĂłn, no querrĂĄ hacerlo.

  9. ÂżUtilizas estrategias de pairing como el ping-pong? En estos casos, Âżno serĂ­a molesto el uso de Git Hooks?
    • En el pasado sĂ­ he hecho pairing con TDD en ping-pong (dirĂ­a que he hecho pairing en todas o casi todas las modalidades posibles đŸ€Ł)
    • Cuando he hecho ping-pong (la persona A escribe el test, B lo pasa, refactor, B escribe el siguiente test, etc.) lo hacĂ­a compartiendo el terminal (es decir, ambas personas trabajĂĄbamos realmente en la misma mĂĄquina, usando tmate). Eso implica que no hacĂ­amos commit hasta que el test no estuviera en verde (y por tanto los Git hooks no eran un problema).
    • Algo que no harĂ­a, independientemente de los Git Hooks, es subir cĂłdigo a la rama principal sin tests.
    • Hay gente que usa esta herramienta, podrĂ­a cubrir segĂșn quĂ© casos de uso (personalmente prefiero no hacer ping-pong y ya estĂĄ, rotamos por pomodoro y ya es suficiente).
    • Sobre pairing, este post es realmente bueno: On Pair Programming
  10. ÂżTener muchos micro commits no puede ensuciar la rama main?
    • Depende de lo que se entienda por “ensuciar”. Lo que siempre es importante es tener commits con buenos mensajes, describiendo muy bien “el porquĂ©â€; y por supuesto ningĂșn commit debe romper los tests.
    • Dicho esto, creo que es mĂĄs importante dar pasitos pequeños y el feedback y flow muy continuos que una supuesta historia de commits “ideal”.
  11. Generalmente lo que se pide es que la feature este completa antes de subir y no quieren ver nada hasta que no esté, ¿Sería aplicable trunk-based?
    • Absolutamente. Para resolver el problema que describes, que efectivamente es muy habitual, existen mĂșltiples tĂ©cnicas de cambios paralelos (incluĂ­ informaciĂłn al respecto) y sobre todo el uso de feature flags/toggles.
    • Esto estĂĄ relacionado con el desacoplamiento que mencionaba durante la charla entre “Deployment” (decisiĂłn tĂ©cnica) y “Release” (decisiĂłn de negocio).

  12. Para usar CD con trunk-based development, a la hora de hacer commits y pushearlos, Âżteniais algun tipo de configuracion para prevenir commit que no pasasen los tests?
    Sí, teníamos configurados Git hooks tanto de pre-commit como de pre-push. En los diagramas de los slides de la charla puedes ver qué incluíamos en cada uno de ellos. Por la forma en que funcionan los Git hooks, si el pre-commit no pasa (i.e. si estado de salida es distinto de cero), no se realiza el commit (idem para el pre-push).

  13. A la pregunta que ha hecho: “Es para cambiar el Mundo, porque en mayor o menos medida cuando subimos un cambio, estos cambian la vida de algunas personas (para bien o para mal) nuestros usuarios o cliebtes, porque tienen herramientas para hacer mejor su trabajo”
    • Entiendo que esto es la respuesta a la pregunta que lancĂ©: “¿Para quĂ© desarrollamos software profesionalmente?”. Me parece una perspectiva maravillosa, la verdad, me siento muy alineado con la idea que subyace a ella.
    • En relaciĂłn con el matiz que mencionaba en mi respuesta y que era lo que querĂ­a resaltar, te dirĂ­a: Âży si pudieras cambiar/mejorar el mundo de manera mĂĄs Ăłptima/eficiente SIN software, no lo harĂ­as? 😉
  14. ÂżTendrĂ­a sentido ejecutar varios procesos de CI en paralelo? Por ejemplo los unit tests, construir la build y los e2e tests a la vez
    • SĂ­, pero depende de cuales. Sin duda debemos paralelizar todo lo posible, comenzando por los propios tests (casi todas las librerĂ­as de testing permiten la ejecuciĂłn en paralelo); ademĂĄs, asĂ­ nos forzamos a escribir tests “autocontenidos”, cuya entrada o salida no dependa de otros tests ni los contamine (lo cual es por defecto lo mĂĄs recomendable). Con los tests unitarios y de integraciĂłn no deberĂ­a haber problema. Con los tests e2e/acceptance tal vez sĂ­ (merece la pena diferenciar cuĂĄles se puden paralelizar y hacerlo).
    • En los dos ejemplos reales que incluĂ­, puedes ver quĂ© paralelizamos y quĂ© no, dirĂ­a que casi todo con mucha consciencia (y siempre mejorable) 😊
    • Si por ejemplo miramos la segunda pipeline, te puedo contar por quĂ© no paralelizamos en concreto las tres tareas que comentas:
      • No querĂ­amos invertir tiempo en el build de la imagen de Docker (y el posterior push a un ECR) si los tests no pasaban antes.
      • Los tests unitarios son los mĂĄs rĂĄpidos, por lo que son los mĂĄs bloqueantes: no queremos hacer nada mĂĄs si eso falla (otro motivo por el que no paralelizarlos con segĂșn quĂ©). SĂ­ los podemos paralelizar con otras tareas tambiĂ©n rĂĄpidas, como linters y otras validaciones estĂĄticas.
      • En cuanto a los tests e2e: en nuestra taxonomĂ­a de testing, esos son tests que lanzamos contra la nueva versiĂłn del sistema ya desplegado en alguna parte (staging o production), por lo que no podrĂ­amos paralelizarlo tampoco con la build o tests unitarios.
      • Los tests que sĂ­ paralelizamos como primer paso de la pipeline son los unitarios (cumplen los principios FIRST), integraciĂłn (en nuestro caso son tests para los adaptadores secundarios de nuestra arquitectura hexagonal) y tests de aceptaciĂłn (que son tests “desde fuera” y los lanzamos contra el sistema que incluye las actualizaciones, levantado “en local”, antes de ser deplegado).
  15. Cuando haces TDD outside-in haces primero los tests desde el punto de vista del usuario pero, Âżcontinuas con tests mĂĄs internos?
    • Exactamente, Ă©sa es la idea. Similar a Acceptance TDD, Specification by Example o Behaviour-Driven Development (BDD) (existen matices de diferencias entre los tres, pero en los tres casos buscamos testear el comportamiento del sistema desde el punto de vista de su usuario externo)
    • Decir que tal vez no siempre sea posible (yo no siempre lo consigo), pero sĂ­ deberĂ­a ser el primer enfoque: cuando se hace asĂ­, la experiencia de desarrollo es fantĂĄstica (y por supuesto tambiĂ©n revierte en la de usuario) 😍
  16. ÂżConsideras indispensable que el continous delivery llegue siempre hasta producciĂłn? ÂżNo serĂ­a suficiente con un entorno de Test que sea una replica de ProducciĂłn para evitar riesgos?
    • No debemos confundir “Continuous Delivery” y “Continuous Deployment”. En la primera parte de mi charla intentĂ© explicar las diferencias.
    • Con “Continuous Delivery”, efectivamente la pipeline no llega a desplegar en ProducciĂłn. Puede, por ejemplo, quedarse en un enterno previo (e.g. Staging). Lo importante es que una vez nuestro cĂłdigo se integra en la rama principal y se ejecuta la build y tests automatizados, queda en un “estado desplegable”: cuando lo deseemos, a voluntad, podrĂ­amos desplegarlo a ProducciĂłn (ese despliegue deberĂ­a ser sencillo y repetible).
    • Con “Continuous Deployment”, ahĂ­ ya sĂ­, toda la pipeline estĂĄ completamente automatizada, incluido el paso de despliegue a ProducciĂłn.
    • En la primera pipeline de ejemplo que mencionĂ©, tenĂ­amos Continuous Deployment pero sĂ­ se desplegaba previamente a un entorno de Staging: tras desplegar ahĂ­, se ejecutaban automĂĄticamente varios tests e2e y smoke (lo mĂĄs crĂ­tico) y si todo funcionaba correctamente, automĂĄticamente se desplegaba a ProducciĂłn.
  17. Entendiendo que una release es un concepto de negocio y no tecnológico, ¿por qué tomar el product delivery lead time es importante como métrica? ¿No es algo fuera del control de tecnología?
    • Buena pregunta. Mi respuesta: porque es fundamental verlo como un “todo”. Desde “ingenierĂ­a/tecnologĂ­a” tenemos que entender que la tecnologĂ­a es un medio para un fin.
    • Para mĂ­ es una de las claves de la evoluciĂłn hacia “product engineering”: entender que TODOS somos producto y negocio, que lo que hacemos debe responder a necesidades de usuarios.
    • En realidad desde “ingenerĂ­a” podemos y debemos influir mucho mĂĄs de lo que creemos en el “product delivery lead time”. Muy a menudo he visto cĂłmo la visiĂłn de los product managers cambia (para bien) cuando los desarrolladores ponemos sobre la mesa formas mĂĄs sencillas de empezar a satisfacer la necesidad del usuario.
    • Evidentemente, es necesaria la cultura adecuada en la empresa para que lo anterior ocurra y no nos encontremos con reinos de taifas y compartimentos estancos donde diferenciemos por completo “negocio” y “tecnologĂ­a”: debemos ir hacia entender que todos somos PRODUCTO y necesitamos colaborar de forma continua e intensa.
    • Por Ășltimo: como yo lo veo, un “product team” estĂĄ compuesto de perfiles varios, todos con igual importancia. El “product manager/owner” debe ser un miembro mĂĄs del equipo, con horizontalidad respecto a los demĂĄs.
  18. Al trabajar siempre en la misma rama, si se hace push al server y algo falla. Como parte de ese rollback Âżse auto generarĂ­a un commit con revert? ÂżO tendrĂ­amos bloqueado la rama principal?
    • Lo primero: hagamos en cada contexto lo que mejor que podamos y sepamos, que ya es mucho 😄
    • En el segundo ejemplo del mundo real que incluĂ­ en la charla, era un rollback muy rĂĄpido del despliegue, por lo que no se generaba ningĂșn commit. Por dar mĂĄs detalles tĂ©cnicos, hacĂ­amos el rollback con helm (que era lo que tambiĂ©n usĂĄbamos para el despliegue).
    • Cuando eso ocurrĂ­a, recibĂ­amos un mensaje en el canal de Slack de equipo que tenĂ­amos para cuestiones importantes (e.g. cualquier fallo en la pipeline).
    • El rollback automĂĄtico en ProducciĂłn nos daba la tranquilidad de saber que se quedaba en un estado estable, que seguĂ­a funcionando lo anterior.
    • En cuanto acabĂĄbamos el pomodoro que estaba en curso (trabajamos principalmente en ensemble), priorizĂĄbamos inmediatamente ver quĂ© habĂ­a fallado y lo resolvĂ­amos. No habĂ­a ningĂșn “bloqueo” de la rama principal porque trabajĂĄbamos en ensemble. Pero si no fuera asĂ­, como comentĂ© en la charla arreglar una pipeline rota debe ser PRIORITARIO, por lo que no es que se quede bloqueada, sino que hay que arreglarla ipso facto, y ademĂĄs todos a una en el equipo, da igual quiĂ©n hizo el commit que lo rompiĂł (creo que el cambio de mentalidad es importante, y el trabajar de forma aislada y muy individualista no ayuda).
    • Trabajando en rama Ășnica con lead time de minutos, no tenĂ­amos necesidad del concepto de “hot fix”: tras el rollback automĂĄtico, en cuanto podĂ­amos lo arreglĂĄblamos (pocos minutos) y comiteĂĄbamos el arreglo que fuera (con un test automĂĄtico incluĂ­do para evitar que se repitiera, de ser posible) y p’arriba 😉
    • Parte de la filosofĂ­a aquĂ­ es que cuando hay un incidente en ProducciĂłn, lo primero y mĂĄs importante es que ProducciĂłn deje de fallar cuanto antes: puede ser porque volvemos a la versiĂłn anterior o porque comiteamos muy rĂĄpidamente una soluciĂłn.
    • A lo largo de 2 años, son muy pocas las ocasiones en las que ese rollback nos ocurriĂł (tenĂ­amos una red de seguridad previa bastante potente). No debemos acostumbrarnos a que estĂ© ocurriendo cada dos por tres, serĂ­a sĂ­ntoma de que tenemos que invertir en mejorar la red de seguridad previa.
  19. ¥Gracias por la charla crack! Me encanta tu punto sobre la disciplina y sobre todo el cuello de botella enfocado en el conocimiento! Tengo una duda, este mundo ha ido evolucionando con términos como CI/CD y otros como DevOps, DevSecOps. ¿Qué opinas sobre esto? ¿Quién debería tener esta responsabilidad, una persona, un equipo? Me encantaría saber tu punto de vista
    • ÂĄGracias! Pues opino de que con DevOps se ha llegado a una situaciĂłn de “inversiĂłn semĂĄntica”: ha acabado significando exactamente lo contrario de lo que se buscaba. Se buscaba mejorar la colaboraciĂłn y derribar silos de conocimiento, bloqueos y pasos de patata caliente, pero en general ha acabado con “equipos DevOps” (en realidad un renombrado del “equipo de sistemas”) que siguen manteniendo el silo, las dependencias bloqueantes, etc. </rant>
    • DevOps es una cultura, no un equipo. Lo cual no es incompatible con tener, por ejemplo, equipo(s) de plataforma o enablers que faciliten la vida a los equipos “stream-aligned” con diversas herramientas y servicios self-service. Pero los equipos, digamos “de producto externo”, no deben tener dependencias bloqueantes de esos equipos.
    • Y lo mismo aplicarĂ­a a DevSecOps, todo lo posible deberĂ­a estar integrado en la pipeline de despliegue/delivery, probablemente apoyĂĄndonos en servicios/herramientas de otros equipos.
  20. ¿Crees que el approach trunk/CI es vålido para resolución de deuda técnica o sustaining como incremento de versiones de frameworks o librerías? ¿O es algo exclusivo de delivery de producto?
    • Totalmente, creo que TBD/CI puede aplicarse a mĂșltiples contextos.
    • De hecho creo que la mejor manera de abordar la deuda tĂ©cnica (que por cierto, tendrĂ­amos que estar seguros de que hablamos de lo mismo 😄) es poco a poco. Hacer “sprints de deuda tĂ©cnica” suele ser sĂ­ntoma de falta de “slack/holgura” en el equipo (entre otras cosas).
    • En cuanto a la actualizaciĂłn de frameworks/librerĂ­as: aquĂ­ ya te dirĂ­a que “depende”.
      • Para actualizaciones de librerĂ­as, te dirĂ­a que sĂ­ (en mi equipo tenĂ­amos un renovatebot actualizando automĂĄticamente a diario todas las librerĂ­as y desplegando al final igualmente la pipeline). Pero de nuevo, lo que repito todo el tiempo: necesitas una red de seguridad potente, sobre todo muy buenos tests automatizados.
      • En cuanto a actualizaciones de frameworks: depende de las implicaciones del cambio. Normalmente sĂ­, pero cuando son versiones major no es improbable que el impacto sea suficientemente grande como para requerir hacerlo en una rama que viva mĂĄs de 24 horas y poder cambiar y probar ahĂ­ todo tranquilamente.
  21. ¿Tienes alguna sugerencia o técnica para ejecutar E2E tests en producción? ¿Tråfico sintético, mirroring de tråfico, etc.?
    Interesante pregunta 😄 La respuesta: “depende del contexto” (sorry, not sorry). Por si te aporta, puedo contarte dos casuísticas muy diferentes que me he encontrado (entre otras muchas):
    • En Clarity AI:
      • Ver la segunda pipeline de ejemplos de la vida real que compartĂ­.
      • AhĂ­ tenĂ­amos varios tests e2e (los que imitan a un usuario real): algunos en Cypress (el servicio principal era una app en Slack (con un slashcommand), asĂ­ que estos tests accedĂ­an realmente a Slack desde un navegador y ejecutaban varios comandos) y algunos en Python puro y duro (peticiones a algunos endpoints HTTP que tambiĂ©n publicĂĄbamos).
      • Los servicios/aplicaciones ahĂ­ desplegadas eran todas para uso interno de trabajadoras en Clarity (300 empleados en su momento), principlamente IngenierĂ­a.
      • Por todo lo anterior, en nuestro caso especĂ­fico la escalabilidad no era un problema: no tenĂ­amos cientos ni miles ni millones de usuarios concurrentes. AsĂ­ que no necesitĂĄbamos tests de carga ni de estrĂ©s, y los tests e2e que tenĂ­amos no necesitaban nada especial.
    • En Form3:
      • AquĂ­ ya la cosa cambia: durante varios meses estuve en el (micro)equipo de escalabilidad, cuya principal responsabilidad era detectar (y a veces corregir) cuellos de botella en la escalabilidad de nuestro (no simple) sistema distribuido.
      • Decir que el producto de Form3 era (o es) un API HTTP en fintech. ManejĂĄbamos muuuuucha pasta diaria y era bastante crĂ­tico (no morĂ­a gente, pero poca broma con la panoja đŸ€Ł)
      • Algo muy interesante es que trabajĂĄbamos mano a mano con la gente de Ventas para generar trĂĄfico simulado conforme a la predicciĂłn “real” de nuevos usuarios (e.g. si se habĂ­a firmado X contratos para cierta fecha, que implicarĂ­a N clientes/usuarios nuevos).
      • Los tests e2e de carga y de estrĂ©s los hacĂ­amos con k6.io (de hecho Form3 acabĂł sacando una soluciĂłn open-source llamada ‘f1’ que lo simplificaba a partir del trabajo que hicimos en mi equipo, es muy interesante, recomiendo echarle un vistazo). CreĂĄbamos una distribuciĂłn de peticiones horaria diaria similar a la que solĂ­amos tener, con distribuciones Gaussianas, pero con los volĂșmenes estimados.
      • Es algo que, la verdad, no habĂ­a visto hacer antes ni lo he vuelto a ver đŸ€Ż
  22. ÂżCĂłmo se puede balancear baterĂ­as de test enormes que hacen que las pipelines tarden, con la rapidez que se necesita en trunk based?
    • Por aclararlo, en Trunk-Based Development (TBD) o CI esa “rapidez” tampoco es tanta en mi opiniĂłn: al menos mergear una vez al dĂ­a en la rama principal. Yo dirĂ­a que cuanta mayor frecuencia, mejor: por ejemplo, cada 2 horas mĂĄximo, mejor que cada 24 horas; y si puedes trabajar con rama Ășnica por defecto y estar haciĂ©ndolo cada pocos minutos, miel sobre hojuelas (en mi experiencia, la diferencia es abismal, pero la vida es dura y hagamos lo que podamos
).
    • Esas “baterĂ­as de test enormes” que mencionas, Âżde quĂ© hablamos exactamente? ÂżPor quĂ© es tan enorme? ÂżEs un gran monolito no modularizado? ÂżEs porque se tienen “demasiados” tests lentos?
    • Como menciono mĂĄs arriba: debemos paralelizar todo lo que podamos. La mayorĂ­a de nuestros tests (sean del tipo que sean, incluso de integraciĂłn y e2e) deberĂ­an ser paralelizables (por defecto, siempre con excepciones, deberĂ­an iniciar lo que necesiten de forma autĂłnoma y dejarlo como estaba antes).
    • Con una correcta modularizaciĂłn, tal vez se podrĂ­an lanzar los tests que nos den suficiente confianza para el despliegue (solo disparar los afectados, tirar de “contract testing”, sĂłlo los e2e/funcionales/acceptance mĂĄs crĂ­ticos, etc.).
    • Y por Ășltimo: es recomendable tener muchos mĂĄs tests rĂĄpidos que lentos.
  23. Tengo sentimientos encontrados con los hooks de prepush y precommit, ya que he visto que en ocasiones han llevado a devs hacer commits mas grandes de lo que debian de ser por no pasar los procesos de linting, tests, etc. varias veces. Te queria preguntar tu opinión sobre eso. Si los has vivido o no, o si los has vivido, como habeis llegado a encauzar la situacion. [Pregunta recibida por Twitter, gracias Eneko 🙏]
    • Lo primero: me faltarĂ­a entender por quĂ© no pasan los procesos de linting, tests, etc. varias veces. ÂżEs porque hay tests flakies o algĂșn tipo de validaciĂłn no completamente determinista? ÂżO es porque los desarrolladores “cometen errores”?
    • No me he encontrado la situaciĂłn que planteas, pero porque hay varias cuestiones a las que siempre marco mucha prioridad con los Git hooks:
      • Tienen que ser MUY rĂĄpidos. Si no, darĂĄ pereza ejecutarlos o esperarĂĄs a tener muchos cambios para hacerlo.
      • Tienen que ser deterministas: no debe variar el resultado si no varĂ­a la “entrada” (tests, linters, lo que sea).
      • Normalmente hacemos TDD, asĂ­ que si algĂșn test falla nos solemos enterar antes, no despuĂ©s (acortar el feedback loop).
      • Tenemos linters y formatters configurados en el propio IDE, exactamente igual que en el Git hook. Eso nos permite tener normalmente feedback aĂșn mĂĄs rĂĄpido y apenas encontrarnos sorpresas cuando se ejecutan los Git hooks. Y
 bĂĄsicamente eso es todo lo que se me ocurre 😅 Como te digo: tendrĂ­a que vivir “in situ” la situaciĂłn para entender bien dĂłnde estĂĄ exactamente la fricciĂłn 😊🙏
  24. La posibilidad de hacer Continuous Deployment Âżno va muy ligado a la criticidad de los posibles errores de la aplicaciĂłn? Es decir, no es lo mismo introducir un bug en, por ejemplo, una plataforma para escuchar mĂșsica que en una app de transacciones econĂłmicas o que maneje datos muy sensibles.
    • En mi opiniĂłn, no 😊 La motivaciĂłn principal para “Continuous X” (Integration/Delivery/Deployment), como mencionaba en la charla (perdĂłn por la autoreferencia) es APRENDER rĂĄpido (para poder adaptarnos y reorientarnos rĂĄpido y poder aportar valor rĂĄpido). Queremos tener feedback lo mĂĄs rĂĄpido posible sobre el QUÉ (necesidades de usuario/cliente/negocio) y sobre el CÓMO (sistemas/tecnologĂ­a/organizaciĂłn). Y eso, por normal general, lo queremos siempre, de hecho se me antoja que en el ejemplo que comentas (y en mi experiencia), probablemente mĂĄs en la aplicaciĂłn de mĂșsica que en la financiera.
    • Tal y como yo lo veo, el razonamiento es el inverso: es para habilitar ese aprendizaje continuo, esos feedback loops rĂĄpidos, por lo que necesitamos entre otras cosas una muy buena red de seguridad que conllevarĂĄ menos errores de la aplicaciĂłn. Reducir los bugs no es un fin en sĂ­ mismo, es un medio para otras cuestiones (mejorar la experiencia de usuario, el aporte de valor, el aprendizaje continuo, etc.)
    • En otras palabras: en la falsa dicotomĂ­a de “calidad vs. velocidad”, en realidad sĂłlo con buena calidad (interna) podremos conseguir la velocidad. Es un tema ya muy tratado e incluso “probado”, por ejemplo en el Accelerate. Hay muchos posts interesantes al respecto, por ejemplo este de Adam Tornhill o este otro.
  25. Parece que intentamos reinventar la rueda pero siempre acabamos volviendo a los conceptos de Eliyahu Goldratt. ¿En qué casos consideras que NO deberíamos aplicar todos estos principios? O por el contrario, ¿los consideras universales para cualquier espacio de problema?
    • Uuffff
 una pregunta difĂ­cil. Resumen: no, no creo que sea algo universal para cualquier espacio de problema. Por ejemplo: si tienes un CRUD puro y duro, donde ademĂĄs “sabes” que no se va a evolucionar apenas (algo que casi nunca me he encontrado, pero venga, imaginemos), entonces no lo aplicarĂ­a. No hay incertidumbre (o eso creemos), no hay gran cosa que aprender. Pero mĂĄs importante aĂșn: es que en ese contexto a dĂ­a de hoy ni siquiera desarrollarĂ­a software, ya hay muchas herramientas NoCode para resolver ese tipo de casuĂ­sticas (e.g. con baja lĂłgica dominio de negocio).
    • Si me pusiera “coach” 😜, hablarĂ­a del framework Cynefin y que en el dominio “claro” estĂĄ “tĂł el pescao vendĂ­o”.
    • Dicho todo esto: creo que es un contexto que, estadĂ­sticamente (al menos en mi evidencia anecdĂłtica experimentada y observada) es infinitesimal, no suele ser el contexto en el mĂĄs frecuentemente solemos movernos y por el que nos pagan.
  26. Cuando por el contexto de las iniciativas, por ejemplo, cambios muy complejos, no se puede mergear diariamente, Âżno se puede considerar integraciĂłn continua?
    • Lo primero: necesitarĂ­a entender mucho mejor ese contexto que mencionas.
    • AquĂ­ voy a hacer “challenge”: en la mayorĂ­a de los casos en los que una persona o equipo me ha indicado que su contexto era “especial” o “demasiado complejo” y por tanto no podĂ­a hacer X o Y, cuando he ido rascando, preguntando, entendiendo, he o hemos visto que los problemas de base eran otros y en realidad sĂ­ se podĂ­a hacer (o al menos empezar a andar el camino). No digo que sea tu caso, porque me falta mucha informaciĂłn, pero sĂ­ digo que casi siempre se puede.
    • De forma muy esporĂĄdica todo vale, somos humanos y es lo que hay (y de hecho hay situaciones puntuales donde no queda otra). Pero si Ă©sa es la situaciĂłn del dĂ­a a dĂ­a, si realmente no podĂ©is mergear diariamente a una rama principal para vuestro trabajo habitual, me cuesta pensar que no sea un problema de conocimiento, principios y prĂĄcticas (es decir, que no sea un problema autogenerado). Probablemente sea “complejidad accidental” y no “complejidad esencial” (ver el mĂ­tico “No silver bullet”, de Fred Brooks).
    • En cualquier caso: si no vas a merger al menos diariamente, no creo que podamos hablar de “continuidad” (y no pasa nada, no es una cuestiĂłn de “purismo lingĂŒĂ­stico”, sino del valor de la prĂĄctica).
    • AquĂ­ recomendarĂ­a trabajar con alguien con experiencia en tĂ©cnicas de cambios paralelos, feature flags, contract testing, aprender a dar pasos mucho mĂĄs pequeños, etc.
  27. ÂżComo serĂ­a el proceso de desplegar funcionalidades del front que dependen de cambios del back con TBD?
    • Tirando de clichĂ©: me alegro de que me hagas esta pregunta đŸ€Ł. De hecho hubo una persona durante el networking que me planteĂł el mismo caso (tal vez fuera la misma).
    • Disclaimer: es mĂĄs que recomendable que todo un value stream se realice dentro de un mismo equipo. Siempre hay excepciones, pero como norma general tanto Front como Back de una funcionalidad e2e deberĂ­a ser responsabilidad del mismo equipo.
    • Por una parte, de nuevo tengo que mencionar la importancia del uso de feature flags para habilitar diversos tipos de cambios en paralelo. Por ejemplo para este caso concreto, podrĂ­amos tener un feature flag tanto en Front como en Back (por defecto Ășnico para ambos), de manera que pudiĂ©ramos desplegar de manera continua cualquiera de las dos partes sin impacto para los usuarios, mientras se va avanzando poquito a poco o esperamos “a la otra parte”. La idea es ocultar al usuario aquello que aĂșn no estĂ© funcionando correctamente porque aĂșn se estĂĄ trabajando en ello.
    • En este punto, me gustarĂ­a compartir una experiencia concreta que me parece muy relevante para este caso: el proyecto en el que trabajamos desde Codium en un cliente y del que mostrĂ© una de las pipelines de Despliegue Continuo que tenĂ­amos (en concreto la del backend)
      • Contexto importante:
        • Formamos un equipo mixto de 3 personas de Codium y otras 3 del cliente (una de ellas como “Product Manager”). HacĂ­amos pairing y ensemble programming por defecto. Y aunque habĂ­a una persona mĂĄs especializada en Front y otra en Back, el resto rotĂĄbamos entre ambos mundos: apenas habĂ­a silos ni compartimentos estancos, en el equipo mĂĄs o menos casi todos hacĂ­amos de casi todo (cada uno con sus fortalezas, claro). TambiĂ©n Ă©ramos muy autĂłnomos para la parte de Sistemas.
        • HabĂ­a una parte de Back (en PHP, con Symphony) y otra de Front (React con TypeScript). Desde el Back publicĂĄbamos un API HTTP que el Front consumĂ­a.
      • Al turrĂłn: usamos OpenAPI para definir el contrato a cumplir entre Front y Back. Cuando se requerĂ­a algĂșn nuevo comportamiento (o cambio) e implicaba cambios en ambos lados, lo primero que hacĂ­amos era juntarnos todo el equipo para escribir juntos el “contrato”. En un fichero yaml, OpenAPI permite definir dicho contrato, e.g. la URI del endpoint, tipos de entrada, tipos de salida, cĂłdigos de estado HTTP devueltos, etc.
      • Una vez tenĂ­amos este contrato escrito entre todos, ya podĂ­amos si querĂ­amos abordar por separado el Front y el Back. Dependiendo del tipo de cambio, en ocasiones no hacĂ­a falta ni “feature flag”.
      • Para asegurarnos de que ninguna de las dos partes rompĂ­a el contrato, tenĂ­amos varias validaciones en Git hooks y la pipeline (en el diagrama que compartĂ­ se puede ver):
        • Backend:
          • Usamos schemathesis. Es una herramienta que automatiza el testing de APIs HTTP, generando dinĂĄmicamente casos de tests a partir del contrato de OpenAPI. Permite mĂșltiples configuraciones segĂșn el nĂșmero de tests que se desean, paralelismo, etc.
          • BĂĄsicamente lo usĂĄbamos para lanzar tests dinĂĄmicos a partir del contrato contra el API publicado por el Back.
          • Lo ejecutĂĄbamos en dos momentos diferentes:
            • En el Git hook de pre-push, contra un entorno local (automĂĄticamente levantado con Docker)
            • Durante la pipeline se ejecutaba por ejemplo contra el entorno de Staging, una vez desplegado ahĂ­ el Back.
        • Frontend:
          • Usamos jormaechea/open-api-mocker, que es un API mocker basado en OpenAPI 3.0
          • BĂĄsicamente levantaba un servidor mock a partir del contrato que tenĂ­amos de OpenAPI, y era quien recibĂ­a las peticiones durante ciertos tipos de tests del Frontend.
        • El fichero yaml con el contrato de OpenAPI estaba tanto en el Front como en el Back: esa duplicidad no era ideal, pero sĂ­ muy “barata” en su momento. En la pipeline tenĂ­amos una validaciĂłn para asegurarnos de que el contrato era exactamente el mismo en ambos lados (y por supuesto nos enterĂĄbamos inmediatamente si eso ocurrĂ­a).
    • IMPORTANTE: la elecciĂłn de estas herramientas fue realizada hace varios años, es mĂĄs que probable que hoy en dĂ­a existan mejores soluciones 😊
    • Si los endpoints del Back fueran consumidos por muchos mĂĄs consumidores (valga la rebuznancia), tal vez podrĂ­amos plantearnos soluciones mĂĄs avanzadas (y tambiĂ©n mucho mĂĄs complejas, mejor esperar a necesitarlo DE VERDAD), como Pact.

¡¡Y esto es todo!! Con esto me quito la espinita de no haber podido dar respuesta a ninguna pregunta tras mi charla 😊

La verdad es que me he divertido mucho respondiendo, ha sido un ejercicio interesante y ya sólo espero haberle aportado algo a alguien 🙏

]]>Isidro LópezSlides and resources from my talk at BilboStack 20242024-01-29T13:26:27+01:002024-01-29T13:26:27+01:00https://islomar.es/slides-and-resources-talk-bilbostack-2024Some months ago, the organization of the amazing conference BilboStack made the mistake of inviting me to talk to the 2024 edition 😆

I decided to talk about Continuous Deployment
 as a Trojan horse in order to talk about many other topics related with software and product development (probably too many indeed! 😅)

Last Saturday, 27th January 2024, I finally gave it: “Valor por encima de código: el poder del Despliegue Continuo”, which might be translated to English as “Value over Code: the power of Continuous Deployment”.

Here I would like to share the slides and some of the people and resources included in the talk (and if you spot any link not working properly, please tell me 🙏).

Also, I have answered in another post all the questions sent during the talk; here you have it in English and here in Spanish.

Oh, and one last thing: I have included 3 extra slides that didn’t appear during the talk
 if you attended, you can try to spot them! 😜

[Spanish] Si quienes asististeis a la charla me pudierais dar feedback (de mejora y positivo, cuanto más concreto mejor), os agradecería ENORMEMENTE si pudierais invertir 2 minutos (de reloj) en rellenar este formulario ¡¡GRACIAS!! 🙏🙏🙏

Slides

Real life examples of Continuous Deployment pipelines

I’ve been “lucky” enough to experience several teams and companies where we grew Continuous Delivery and Continuous Deployment pipelines. Here I would like to share two specific examples:

Diagram with a Continuous Deployment pipeline

Diagram with a Continuous Deployment pipeline

Other resources

General

Continuous Integration, Delivery and Deployment

Lean and Flow

Parallel changes

Workshops about parallel changes

Canary releases and Blue-green deployment

Trunk-Based Development

Branching, Pull requests and blocking code reviews

(Vertical) Slicing

]]>Isidro LĂłpezSome interview questions as an interviewee2021-11-10T13:05:34+01:002025-09-23T11:01:31+02:00https://islomar.es/some-interview-questions-as-intervieweeThis post is the extraction of a section at my page My professional services. Some people enjoyed this part especially, so I thought it might be a good idea to extract it as an independent post that I might update from time to time.

The goal of these questions is to help clarifying my expectations and to generate the clearest and broadest possible idea about the company, the business, the culture, the role, the day-to-day work, etc. To better grab the “lights” and the “darkness”. Another outcome is to reduce the probability of a misalignment and big surprises during the first weeks of work 😊

And always remember that an interview is (or should be) a 2-ways conversation, a 2-ways discovering process.

Besides having many general questions, some of them depend on each specific role and company. Here some things that I do to get so much information as possible for getting some specific questions:

  • Carefully reading the job advertisement.
  • Carefully reading their engineering blog or publications (in case they have them).
  • Reading the “Careers” or “About us” from their website, any page with information about their culture, etc.
  • Reading their information in LinkedIn.
  • Look for news related with the company.
  • Look for them in Crunchbase
  • Look for them in Glassdoor
  • Contact through LinkedIn with any acquittance you might have there, in the present or past, in order to ask them about their opinion (always with respect and maximum sensibility).

So
 here I share some of the questions that I have asked in the past or I will ask in the future to my interviewers; I would recommend you to select only a few and prioritize them according to the time that you have available, and taking into account the different stages during the recruitment process.

  • What is your mission and short-term goals as an organisation? What is your vision and long-term goals?
  • What is the business model of the company? Who are your customers, users, providers?
  • What differentiates you from any other company and from your competitors?
  • How do you earn money, what are your revenue streams? Did you surpass the break-even?
  • How do you improve as a company or team? How do you learn?
  • How are you organised? (company-wide and engineering)
  • How do you take decisions? Who takes which ones and when? What decisions are taken at each “level”?
  • How do you communicate? How do you get feedback in all the needed directions?
  • How do you keep the whole organisation aligned?
  • Do you consider the company a remote-first one? E.g. is there any company or team event which does not happen online? Can I enjoy my own local bank holidays? Will you pay for any expense related with an on-site gathering?
  • Are there explicit actions in place to take care about Diversity, Equity and Inclusion (DE&I)? E.g. do you have numbers about gender diversity? About age diversity? What about diversity in leadership and management positions (C-level included)?
  • What opportunities exist for mentorship?
  • What do you enjoy the most from working there?
  • Tell me something that you don’t like here. What room for improvement exists? What would you like to be different, why and how?
  • What are the current main challenges for the company? (product and technical challenges)
  • What are the main challenges in the team that I would join? What are the current main pains?
  • Why would you fire me?
  • Why are you hiring for this specific position? Is it a new team? Is it a backfill? In case it is a backfill, why, what happened?
  • Psychological safety is extremely important to me, so please be honest with me: are there verbally aggressive people, especially in positions with power?
  • Is there micromanagement from any position with power (e.g CTO/VP/Head/Managers)? How do they intervene in team’s decisions if they don’t agree?
  • What would be my boundaries? What wouldn’t I be allowed to do or to step into?
  • What do you expect from me?
  • Why don’t you cover this position with a current internal employee?
  • Do you have a structured onboarding plan for me?
  • Who would be my manager? I would like to talk to them and understand their vision and expectations about me.
  • Why did the last 2 people of Engineering left? How did you handle it?
  • Why did the last 2 people of Engineering were fired (or made redundant 😉)? How did you handle it?
  • How do you take care of people?
  • Can I talk to any potential peer, specially someone already doing the same work? Can I talk with a team?
  • What does a team look like there?
  • How would you describe your ideal colleague? And your ideal team?
  • Who decides how a team works? (“rituals”, principles, practices, roles, etc.)
  • What does “technical/engineering excellence” mean to you?
  • Tell me about your infrastructure and platform. What is automated? Can the “external product teams” deploy on their own?
  • Tell me about your observability practices. How do you find out that there is a problem? How do you dig deeper to solve it?
  • What happens when an incident in Production is detected?
  • Tell me about your main technical principles and practices.
  • Is it needed to do on-call outside of working hours? (from my timezone perspective)
    • How often?
    • How many production incidents do you have while on-call per week?
    • Is it paid extra?
  • What is approximately your lead time (time from a commit to Production), throughput (frequency of deployments/releases to Production) and error rate?
  • Could you tell me which is the whole lifecycle of a user need? Could you describe for me any of your main value streams? From the discovery of the user need until its satisfaction.
  • How and when is the priorization done? Who does it? Based on what?
  • How do you optimize the business and technical alignment of the teams?
  • How do you handle disagreements on technical approaches?
  • What happens from the moment a developer starts working on something until it is deployed? Could you please describe to me your delivery pipeline? What’s the full journey of a commit?
  • How many teams does a team depend on to get a small change into production?
  • What is the entire process for a one line change in code to make it to production? (by Jeremy Kahne)
  • Do you decouple “Release” from “Deployment”?
  • What is a typical day of a team? (from the very start to the very end)
  • Do you support open source in any way?
  • How does the whole recruitment process work? Which will be the next steps?
  • What is the salary range? Social benefits?
  • Is there any budget for training or any other concept?
  • Would there be the possibility to work 30-32 hours per week (6 hours per day or 4 days per week)?

More questions from other people

]]>Isidro LĂłpezYAHWP (Yet Another Hello World Post)2020-06-29T21:22:00+02:002020-06-29T21:22:00+02:00https://islomar.es/yet-another-hello-world-postReintento nĂșmero 459347 de escribir un blog de manera sostenida en el tiempo: ÂĄÂĄaaaaaacciĂłn!!

Pues nada, jazztamos aquĂ­. Ocho años despuĂ©s de mi Ășltimo intento de arrancar y mantener un blog (“El reposo del guerrero” por aquel entonces, tres posts durĂ©, que la tierra le sea leve), voy a intentarlo de nuevo.

El porqué de las cosas

¿Y por qué escribir? ¿Y para qué escribir? ¿Y para quién escribir? Bueno, me vienen varias respuestas a la mente:

  • EscribirĂ© principalmente para mĂ­:
    • En ocasiones como recordatorios para mi yo futuro, tanto de cuestiones tĂ©cnicas como sobre mi pensamiento en un determinado momento sobre el tema X.
    • En otras ocasiones para “obligarme” a estructurar mejor lo que pienso sobre algo. No hay nada como tener que expresar o explicar algo, para ayudarte a interiorizarlo mejor.
    • Y como refrito de lo anterior: para aprender. Tanto por el proceso de escritura como de las posibles conversaciones que surjan despuĂ©s con quien lo lea.
  • Aunque no solo para mĂ­ (para eso no harĂ­a falta publicarlo): por muy obvio que nos parezca algo, siempre habrĂĄ a quien lo que una sabe/cree/piensa le aporte algĂșn valor (lo que sea: algo tĂ©cnico, polĂ­tico, espiritual, etc.). OjalĂĄ algo, en algĂșn momento, desde la humildad, le sea de utilidad a alguien.

¿Y cómo lo haré?

No me es fĂĄcil, pero intentarĂ© no sucumbir al sĂ­ndrome del folio en blanco, al tĂ­pico bloqueo por querer escribir algo “interesante”.

En 2010 descubrĂ­ a Seth Godin. Un clĂĄsico: fue haciendo un Executive MBA (ya solo eso da para un post), donde era uno de los referentes para todo lo relacionado con marketing (por supuesto devorĂ© “La vaca pĂșrpura”).

A lo que voy: Seth Godin escribe un blog desde hace mil años, el cual sigo y recomendarĂ­a seguir a todo el mundo. Pero lo que siempre me ha fascinado de su blog, mĂĄs allĂĄ del contenido, es que escribe absolutamente TODOS los dĂ­as (al menos que yo sepa). Lo que me flipĂł cuando le conocĂ­, es que a veces publica un post con una sola frase o lĂ­nea. Una. Ya. En ocasiones se extiende mĂĄs, en ocasiones menos, pero nunca “demasiado”


AsĂ­ que ahora mismo mi intenciĂłn es probar ese formato (no escribir a diario, sino escribir aunque solo sea una frase si me apetece) y alternar artĂ­culos de diversa extensiĂłn (aunque estoy seguro de que en alguno me extenderĂ© “demasiado”). Veremos quĂ© sale.

¿Y sobre qué tontås vas a escribir, muchacho?

En la secciĂłn “Sobre mí” he intentado escribir un poco mĂĄs
 sobre mĂ­ (sorpresa) y tambiĂ©n sobre aquello que me interesa y de lo que probablemente escriba en algĂșn momento. Nada cerrado, asĂ­ que imagino que eso repelerĂĄ a algunas personas y atraerĂĄ a otras. Me gusta ver los sistemas en su conjunto y eso me incluye a mĂ­ mismo.

También decir que durante las primeras semanas probablemente iré cambiando bastante la estructura del blog o su look & feel; probaré diferentes layouts, secciones, configuraciones, etc. De aquí a un mes espero que esté ya estabilizado.

Y aunque empezarĂ© en español, no descarto alternar con el inglĂ©s en algĂșn momento.

ÂżAlgo mĂĄs?

Que se aceptan opiniones y consejos. No para seguirlos necesariamente, pero nunca se sabe de dónde puede venir una idea interesante de mejora 😊

Y ahora sí, nada más por ahora: buenos días, buenas tardes y buenas noches 😉

]]>Isidro LĂłpez