DevOps Challenge Day 1⚙️: Introduction to DevOps

@Vipin @mmario.ffrohlich @alex_read @SabotageAndi @sanjaykumar @future @paulsbruce @danielknott  @Daniela23 - I would love to hear your points on this topic

I present to you my take on DevOps principles. 

Disclaimer: no AI was used while writing this, several cups of coffee bravely laid their lives for this to happen.

Key DevOps principles:

1. Collaboration/communication

Every article I've read mentioned collaboration/communication as the first key principle, and with good reason – without quality, transparent, and clear collaboration/communication, there is no way that the end user will get a high-quality product. I mean, the term itself reflects that stance as it is a result of combining the terms developers (Dev) and operations (Ops). However, this is easier said than done, as every member of the team has their priorities and stance towards the task at hand – devs want to write code that gets the job done and move to another task; sec. team wants to ensure that the product is as safe as possible; testers want to test the feature; the automation team wants to write automation tests; stakeholders want to get the product out as fast and as cheap as possible, etc. It takes some time to get all of those people on the same side and to create that 'we-are-working-for-the-same-goal' attitude within a team. However, once that level of collaboration is achieved, the result (final product/feature/[enter-your-term-here] will result in high-quality output.

Furthermore, when talking about communication, there is one aspect that's easily overlooked – feedback. Positive feedback will send the team skyrocketing as it boosts its morale and creates a more positive work environment. Consequently, negative feedback will often, as we are all humans, could hurt the team. The main problem here is that negative feedback often hits a person's ego, people get offended (god complex anyone?) and start spreading negative energy through the team. People often overlook the fact that negative feedback should be viewed as an opportunity to learn which/what part of the person's skills should be improved which will, in turn, make a person even better team member/employee.

To conclude, once the collaboration and communication taken to a higher level, the team will (should) work as well as an oiled machine. Feedback, good and bad, should be viewed as an opportunity to get better at your job – don't let that ego monster get you because, once it spreads, it's hard to contain it.

2. Automation

One of the key features/benefits of a properly set-up DevOps team is the speed at which the software is delivered, updated, patched… It's an essential practice to automate as much SDLC as possible. Automating as many steps as possible will result in faster software delivery, which could result in more potential customers. It also affects the team – with more automation fewer tedious tasks should be performed, and the team has more time to focus on developing new features, spending more time on improvement of skills, researching new technologies, etc.

However, it has to be taken into account that automation isn't absolutely everything and that it's not possible to automate everything. There is a fine line between what is worth being automated and what will take more time to automate than it takes to perform the task itself. 

3. Continuous improvement/delivery

There is a strong emphasis on continuous improvement in DevOps culture/environment. It is based on the premise that the first goal is to hit the minimum viable product (MVP) and then to build on top of that.  So, once the MVP is hit, the team will switch their focus on developing new features, thinking of a way(s) to make the product faster, and stable, thinking of ways to reduce its costs/increase profits… It benefits customers too as they have faster access to the core aspects of a product, have time to learn and adapt to new features, and time to get comfortable with the product in general.

4. Customers, customers, customers … from the beginning to the end

The customers should be viewed as a central focus of the DevOps lifecycle. Everything done with software, every change, upgrade/downgrade, everything should answer one simple question – how and will this benefit my customer? If embraced this will result in happier customers that will use the product for a longer period which could lead to new customers.

Furthermore, the product customers are valuable sources of feedback which is then used to improve the product even more – are there any areas of friction that need to be addressed; is there any potential issue that could be negatated before it even arises; what parts of the product are customers using the most and could/should they be improved, etc. Basically, it all boils down to behaviour-driven development – once the customers needs are defined, the development can be focused on addressing those needs. This also reduces the waste as every member involved in the E2E flow of the product understands each other, recognizes it's needs and possibilities and work as one towards the shared goal – high quality product

It got caught by one of our filters for no good reason. Caught and released now 😊