Break down the silos
A traditional product team would have testing being done by dedicated testers, but today you would need testers who have knowledge and exposure to coding as well. This is because most QA today involves automated testing and testers would need to know how to write code that would result in automated testing and also deployment. It is always possible to go out and hire new talent which is proficient in both coding and testing, but a much better idea would be to upskill your present testing team.
Paas is passé
With the boom in the popularity of cloud computing in recent years, many developers had moved towards the use of platforms as a service instead of using specific platforms in containers. But to make the development lifecycle more flexible and easily changeable according to user expectations, the platforms must be used in a container structure.
As soon as you begin moving to a DevOps approach, you will find your team generating more and more useful data. If your team is not taking steps to collect, store and analyse this, you are letting go of a big opportunity. You might find initially that implementing artificial intelligence or applying machine learning on your collected data eats up a lot of money and storage space, but in the long run, you will see that it only enhances the end product.
No More Servers
The series of ‘aaS’ (as a service) that we have seen in recent years has given rise to a new one – function as a service (FaaS). Applications can now be run without having to maintain and manage humongous servers, and the cost charged to the user would be on the basis of the number of invocations of each function. DevOps is embracing ‘serverless’ in a big way which is expected to push down costs.
Automate or Perish
The theme of automation has been around since the time DevOps started becoming popular, but its relevance has only increased over the years. The race for diminishing resources had all but made manual testing irrelevant. Automation also enhances speed, by allowing more testing cycles to be completed at the same time.
If you are pushing for the DevOps philosophy in your organization, you will surely need to measure certain aspects of your process so that you can highlight the clear benefits. The metrics you choose to measure, analyse and highlight should focus on at least the speed or the stability, but preferably on both. Some examples could be the time taken to deploy, the time to successfully implement a change, the time is taken to repair, the rate of failures etc.
The technical metrics listed above, along with the business metrics (profitability, business pipeline, conversions etc.) will lay the foundation for the path the organization would need to take. Once that is in place, it would create a solid foundation for BAU activities, yet lead the path for calculated tactical risks. The advantage of a metrics-driven organization is that they can set for themselves the limits up to which they would be willing to experiment and absorb resultant losses if any. But innovation will have to become the name of the game as we move ahead.
One of the emerging trends, as we move forward on the DevOps path, is the return to basics. You would recall how important the agile methodology had become in the traditional software development process. That is set to make a return in DevOps as well, so you need to keep the DevOps framework flexible enough to incorporate the agile philosophy.