How has release and change management changed on IBM i?
Over the years, IT teams have moved from Software Change Management, to Application Lifecycle Management and now to DevOps as the norm for release and change management practices.
How has change management evolved from 1992 to 2021?
Remain’s TD/OMS (originally OMS, or Object Management System) was first released in 1992 as a tool for the deployment part of the change management process.
In the beginning, there wasn’t much emphasis on what the developers did.
Unlike competitors at the time, Remain started from the perspective of the operator – not the developer.
TD/OMS would give developers a task to create the objects as they want, attach them to the task and then let the operators know.
Operators could then take the task and all the objects that are attached to it and deploy it first to test, and then deploy it out remotely to all the production machines.
Later on, the focus shifted to include the developers and the end-users, making it a more whole, end-to-end process.
Early on, Remain added further tools and features to help the developers with compilation, editing, and dependency management. This meant that, when a developer would change a file, they could see which objects were using that file and perform a proper impact analysis.
Eventually, though, end-users finding issues were wondering where the link was between the business and the change process.
As the cycle has grown and matured, it has become focussed on operations and deployment first, then on developers.
Finally, the business side of change management has also been enveloped into that IBM i change process.
ON to the future of TD/OMS
Any time you develop a release, you think “this is absolutely the best version ever”.
And yet, the best developers keep programming and keep finding things to add to that mix.
With APIs and other products within the Remain Software suite, what is going to be important in the coming years is the mix of other systems and integrations.
“The IBM i is no longer the central system for the database, and it’s certainly not the only system anymore. We’re seeing applications offloaded to different platforms, and to web applications. We’re seeing more graphical user interfaces and a recent surge to mobile applications” says Wim Jongman, Co-managing Partner and Chief Technology Officer.
“Part of DevOps is ensuring that the team takes these changes into account. As an example, when a file is changed on the IBM i, you need to ask yourself, what is the impact of the change? You need to consider the impact not only on the IBM system but also the impact of the change across all of the sources in the enterprise”.
“That adds complexity to an already-complex process. Where, in the past, you would have this IBM i with RPG going to test and then deployed to the production machine, but now different systems have been added. You have to conduct an impact analysis across all sources in the enterprise”.
As another example, when people are developing in PHP or Java and in Web archives, they may also want to know whether those programmes can be deployed to the Tomcat server to the Unix server.
So those things are added to the DevOps system.
TD/OMS isn’t just a standalone platform.
There are a couple of established tools in the DevOps arena, for example Jenkins, which is described as the ‘switch knife for software deployment’.
Jongman explains more:
“Jenkins started as a system that could be used to build an application. When a developer ships into Git, Jenkins would pull all the source files into a single jar file, which could then be deployed. Then people started to use Jenkins as a deployment system as well. It became the centre point of DevOps deployment.
Jenkins doesn’t deploy to the IBM i, though. But because it was built out of plugins, code can be added to allow Jenkins to do a deployment of a Web application or Tomcat server. Remain made a plugin for Jenkins, which tells TD/OMS when to put a release into production, so you can continue with the next step of the process”.
What is continuous integration and what does that mean?
Continuous integration says that, when a change is being pushed inside the repository by a developer, then the automated process should be able to take that source and compile it to an application.
The programme should then be able to run all the unit tests on that application. And if all the unit tests are green, then the process should be able to push that change into the production environment.
Continuous integration aims to make the complete process automated.
When a developer makes a change, that process of compiling, testing and deployment is automated from that point on. Whenever somebody pushes something into the repository, TD/OMS takes that and starts the whole process again by pushing that change back into the production environment.
Learn more about DevOps & IBM i:
- Demystifying DevOps on the IBM i: What is DevOps and why is it important? | Get a better understanding of the DevOps change management process
- Benefits of DevOps on IBM i | Discover why and how the DevOps process is suited to the IBM i platform
- How do you manage the DevOps process on IBM i | Follow a step-by-step process for implementing DevOps on IBM i
- How has release and change management changed on IBM i? | Learn the history of DevOps and change management for IBM i developers
- Managing the DevOps process on IBM i with TD/OMS | Find out how TD/OMS from Remain Software supports change and application lifecycle management on IBM i.
About Remain Software and TD/OMS
TD/OMS is a collaborative multi-platform software change management tool from Remain Software.
It follows industry DevOps change management standards, adapting them for DevOps on IBM i.
TD/OMS supports change and application life cycle management on IBM i, from development and testing to acceptance and deployment. TD/OMS enables business of any size to go-to-market quickly, with high-quality software applications and minimal bugs.
Posted by Zoe on 9th September 2021.