You may not be familiar with the concept “community of practice”, (CoP from now on) so let me start this entry by giving a short overview. Essentially, we will be talking about a group of people with a trade or
Dealing with distractions as a DevOps
Being a transverse department, every DevOps must learn how to deal with issues. It’s a common pitfall that, embracing the agile philosophy, the team ends up accepting that word of mouth is a tolerable method to track or inform problems.
Culture change does not happen overnight
One of a development’s department most critical endeavours is Change Management. Even in a technological environment, people tend to use those tools and methodologies that they are more comfortable with. Stepping into the unknown throws your workers off-balance, affects their
The problems of legacy systems
Many companies do not understand that they actually are “technological companies”. The fact that their “product” (meaning whatever item or service they base their business on) is not directly tied to software development weights so heavily in their mindset that
Define a valid Rollback strategy
How do you deal with broken builds? Applying methods like Continuous Integration or Continuous Delivery usually make the lower development environments (usually tagged “integration” and “UAT”) unstable. As several teams merge their changes to the software, the end-to-end tests might
How to recruit a DevOps
In my blog I usually talk on technology on a “management” level. My aim was trying to explain technical concepts without the “technical” part. Why should any company invest money in something, unless they understand fully what are the benefits
The benefits of automated testing
Read carefully this statement: If your development pipeline does not include any degree of automated testing, you are wasting money. Don’t lose your temper, breathe slowly… Now read that again. Yes: you are losing money. Testing is burning up your
Is your team wasting too much time on meetings?
Stop me if you heard this one before: “agile has too many meetings“. This is the most common complaint for teams adopting scrum or other similar agile methods. Developers feel that they are wasting their time instead of “doing stuff”.
No one reads the documentation – and that shouldn’t stop you
I could make a post with the perfect tone mix of “amusingly angry” and “cynical tech guy” on how no one ever reads the manual, but this is not about making a point on how clever “we” are versus how
What is it that makes a good developer?
I’ve always found that, when interviewing someone for a technical position, the round of time talking about actual technical knowledge is the one taking the smallest fragment of the conversation. And this is because all technology can be learnt with