DevOps strategies for your IBM i


I believe that IBM i developers can have a meaningful discussion with Java developers about the merits of DevOps. It is the case that we (IBM i devs) have for long implemented many of the "new" concepts like isolated development environments, automatic deployments, and isolated and protected production environments. When using a DevOps tool like TD/OMS, the concepts of task-based development, automated builds and deployments are also well established. However, there are some new ideas that seem wild west at first but are amazingly effective when implemented. Let's go over some of these DevOps ideas and see how we measure up on the IBM i.

If you fear change, leave it in the tip jar.

We fear change more than an average Java developer does. Especially when a big one comes around, we start to worry about how this will block other development. This is because we integrate too early. In my opinion, a change should only be integrated when it is 100% certain that it will go to production. Not sooner.

Java and PHP developers are less worried about other development. They just start coding and only worry about integration issues when it is time to promote the change to production. I believe that IBM i developers can also have this worry-free state of mind. It is much better for creativity.

We integrate too early

One of the DevOps mantras is: Integrate early. You may be surprised to know that we (IBM i developers) typically integrate too early. We often integrate right after the development environment (QA in this picture).

The initial problem with early integration is that we probably are going to find issues just after development, which puts all other changes in QA in an unstable environment. Secondly, there is no guarantee that the change will be successfully promoted to production. If the latter is true, then the change might potentially block other changes from going to production because their changes were based on this one.

Each change on its own branch

To make sure that we do not integrate too early, we have to make sure that we put each change on its own path. In this way, we can isolate changes from each other and only integrate when we are 100% sure of this change.  In this picture, integration means moving the changes to the PRE environment, which is built for this purpose. Changes are parked here until we have a window to deploy to production.

However, we do not want to wait for ages before our changes are deployed to production. In fact, we can wonder if we even need to have an integration environment. Why not deploy to production when the change is ready and say, "Good riddance!"

Good riddance! (Deploy to production as soon as possible)

What prevents you from moving a change to production once it is done? Done means that the change is made, it has undergone automated and manual testing and is signed off.

This change then becomes available for other people to build upon, and they do not have to go through the retrofitting process like when their changes are being made concurrently.

Obviously, this is not possible for all changes. Some changes need to be implemented on a specific date because of new regulations or other reasons. But probably most small changes should be able to go as soon as they are ready.

Conclusion

I have presented you with an alternative way of thinking about your development environment. These methods can be implemented in every development environment, regardless if you use tooling or not. However, people who use TD/OMS are happy to know that branching comes included, out of the box. It enables you to isolate changes until they really need to be integrated.

Contact us if you want to know more about TD/OMS and our ideas on effective software development on an IBM i.