DevOps on IBM i #37
Labels
git
git topics
Comments
|
Great read Liam! I have been talking DevOps for over 5 years and nice to see it resonate in the IBM i community. Would love to talk about Barry CI on our next go around. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
DevOps on IBM i is such a hot topic right now and I wanted to write about different areas of DevOps and how you can achieve them on IBM i to create an environment for continuous development.
Why DevOps compared to change management
Change Management Software (CMS) on IBM i has been around for a long time. CMS handles a lot of development work for you, like handling object & table dependencies, deployment and some even have project management tools in them (or some kind of integration to another). There are still a lot of businesses in the IBM i industry which have not adopted any CMS or source control.
CMS has traditionally stored versions of sources and objects. In some cases, I've seen businesses that have the object stored in their change management, but not the source for it - meaning there is no way to make changes to it without re-writing. Because of the way that CMS traditionally stores source code, it's not particularly easy to roll back. I also discovered recently that not all CMSs will stop tracking sources/objects after a certain amount of check-ins (which is usually configurable).
Of course, while some CMS have changed, most still stick to the check-in / check-out process. This is a real killer in development time in some shops.
DevOps (and the tools inside of it) solves a lot of these issues, such as tracking all history of source code. DevOps is primarily a great piece when it comes to delivering software to your users or clients: which not only involves the build, but also the deployment to multiple servers. As you'd expect, with the right tools, your DevOps pipeline should only deploy pieces of code that have changed with minimal downtime in an automated process.
With a smooth DevOps pipeline, you should expect to be able to deliver software at a faster pace and into production quicker for your customers or clients. The idea that code can be developed and tested (through automated and QA testing) at the same time is great for a business that wants to find bugs before they deploy to production but at a faster pace.
Speed of Development
Because of the distributed development model, developers should be able to make changes to the application without stepping on each other's toes. It means that one person can make changes and get them into QA without affecting or waiting for anyone else.
Fast delivery process
The deployment pipeline is automated in all areas, which means it is easier to test and deploy your application faster, which results in a better result for your clients and customers. With DevOps, not only can you do staged releases, but you can also write, test and deploy on an automated basis. This is really where CI/CD comes into action, to create the pipeline for testing and deployment.
Collaborate together
A new development model means that while your teams can stick to their normal development model of check-in/check-out, it also means they can work more collaborative way. Since the distributed workflow allows for developers to work on the same sources at the same time, not only does it mean it's faster to make changes, but that it's faster and easier to share projects and changes together. No more waiting for other people to finish their changes before you can put your change in.
Continuous Integration
Continuous Integration (CI) is the model where developers are continuously pushing their code changes into a central repository (which on IBM i is usually git), in which would trigger a configured pipeline to run your build process and tests automatically. The goal of CI is to address bugs faster and improve the quality of the software you are developing, which in turn makes it faster to deploy software to your clients and customers.
Continuous Delivery
Continuous Delivery (CD) is the part in which your application is automatically built, tested and deployed onto your production systems. CD usually continues on from CI and should deploy changes into testing environments (automatically) after the build stage. When CD is implemented properly, developers will always have a production-ready version of the application that has already been tested and is ready to move to production.
The cost of DevOps on IBM i
The real cost of implementing a DevOps environment on IBM i is time, learning & resources. Because of the way source code has traditionally been stored on IBM i, there is a huge leap in needing the source inside of the IFS (because of git). Not only migrating the source code, but your team would need to learn new workflows (git & distributed development).
Most CI/CD environments and pipelines can and are implemented in-house to support the nature of your application. Paying for tools usually is not a problem, because the majority of them are cheaper than your traditional tools.
Some prices of tools at the time of writing this blog (which of course are subject to change):
Unless you use any service to create your pipelines. You will probably need another partition running Linux (or whatever their requirements are) for Bamboo or GitLab (on-prem) since neither of them can run IBM i - but that really should not be a problem.
Further material
IBM i Software Vendors that claim they can do DevOps:
Note that while I put links to vendors here does not mean that you cannot implement your own DevOps environment. I do not endorse any of the vendors I have linked, but instead, am making the readers aware of what is available. It is very much possible to implement your own DevOps environment.
The text was updated successfully, but these errors were encountered: