10 posts tagged with "softwaredevelopment"
View All TagsDelivery Acceleration: Parallel Changes Strategy
As we develop a product over time, changes need to be made as we need to accommodate new functionality. As most of our systems don't run isolated, and we have clients that used them (ex. public API), We have to keep compatibility at least on a temporary basis. How do we achieve this?
Delivery Acceleration: Version Control Integration Strategy
I have already written some other post on this topic. I will go straight to the point on comparing Git Flow (a legacy strategy that most companies use) and Trunk-Based Development.
Delivery Acceleration: Testing & Validation
Before we enable code for our clients, we need to test and validate it does what is expected. This could be an entire series of its own (please let me know if you want one), so I will keep it on a high level.
Delivery Acceleration: Enabling Features
Now that we know where our code lives, we need to make sure our users get access to the features. For this, we need to get our code to the environment we want to deploy to, and control the rollout (if you are not a big bang release fan).
Delivery Acceleration: Deployment Environments
Our services need to run somewhere, so our users can access it. It's a very common practices to have multiple environments like dev, staging, and prod. Is this actually a good practices?
Delivery Acceleration: Observability
When we talk about observability, we talk about:
Capability of developers to understand the health and status of their application.

We don't want users or clients to be the ones noticing something is wrong. For this, there are multiple tools that fall under the observability category.
Delivery Acceleration: DevOps Mentality & Practices
When we start our journey towards continuous integration & delivery, the first thing to take in count is the mentality. There are a few of them that will make or break our intent. Let's see the most important and also some practices.
Delivery Acceleration: Intro
This is a series I am really looking forward to writing. I have been doing this presentation for the last 3 years in multiple places.
The future of teams: Crossfuctional & T-Shaped
In software development, over the last years we always talk about on cross-functional teams, as a good split of responsibilities to provide autonomy in teams. What does that mean? Why is this so? And what does it look like?