Recently at a customer site we discovered a great use case for the Project Release field when used in conjunction with Release Management. This organization required 2 different change types. Firstly, changes to be deployed in the morning. These changes having been assessed to not impact production stability. Secondly, other changes to be deployed in the evenings. Changes that couldn’t be introduced while the business is using the production system. In this case, the developer could determine whether the change required morning or evening deployment and could assign the schedule.
Last posting I mentioned some component areas, tenets for success, SAP IT teams will need to address on their journey to a fully implemented DevOps approach. In this post, I’ll elaborate on the first couple. To progress towards a DevOps approach, change control processes need to be robust and clearly understood by all involved. Development, QA, Testing, Business and the Functional teams. There are different types of change, and so changes will be processed in different ways. It’s not rocket science, but it is still surprising how many teams still struggle with this relatively simple concept. Managing change with a ‘one size fits all’ single process will not work in a DevOps / agile environment.
For SAP customers, effective automation and integration of SAP change management processes with an organization’s ALM processes – such as testing, code inspection, other change/incident management, and impact analysis solutions – can have a significant impact when embarking on large-scale, strategic IT initiatives. We’ve known this for some time, but it was validated in a recent Gartner article by Susan Moore who points out that Automation of IT Infrastructure and Operations (I&O) provides significant benefits to organizations including improved accountability, efficiency and predictability, while reducing cost, variability and risk.
We’ve discussed here lately how SAP Change Control solutions like our own Rev-Trac can help integrate major ALM applications into a smooth, end-to-end IT infrastructure, DevOps style. You don’t need to disturb your current processes to do it. But how does that relate to real-world problems? Has anyone actually tried it?
Having read a reasonable amount about IT agility, ‘agile’ development methods and so on – and even having run the occasional webinar on the subject − I’ve long viewed technical agility as a worthy goal. The trouble for most companies … Continued