DevOps
why adopt it and how to get started?

Application deployment is the most critical phases in the software development lifecycle. A decade ago, deployment was infrequent and a mostly manual and complex endeavor, scheduled at most monthly, quarterly, or even annually. Given the scale of change involved, software upgrades created contention between development and operations teams. At that time, development teams had already adopted mainstream agile methods and were releasing smaller software increments faster and more frequently, while operations – upholding their corporate constraints around application availability and compliance – became an apparent bottleneck in the process.

DevOps has become a common practice in many organizations to respond more easily to these issues and more effectively to their business challenges. Today’s digital transformation requires the time-to-market speeds that only DevOps can deliver. Organizations that have embraced DevOps either to the full or even partially can already testify that this approach brings a significant ROI.

Today the question is no longer whether organizations should adopt DevOps, but how to implement it successfully and extend it enterprise-wide. The concept of Enterprise DevOps elevates DevOps into a business strategy, a process that adds value to the organization, not just IT.

To learn more about evolution of DevOps, you can read our articles The evolution of DevOps and Why DevOps? or even download our White Paper Enterprise DevOps.

The emergence of new DevOps-related terms reveals the level and extent of communication needed across all departments to progress the way business changes are managed. In DevSecOps, for example, security is enhanced by making it a shared responsibility and addressing it early in the application development process. Below we’ll examine how to achieve a single, common DevSecOps pipeline spanning all technologies, including IBM i. We will see how to automate an end-to-end DevSecOps cycle on IBM i – integrated with open source and cloud.

DevOps is helping organizations respond quickly to market changes, delivering better software updates to users faster. But moving to full DevOps can be challenging for IBM i teams faced with project deadlines, with little time to transition to a new full CI/CD model.

ARCAD helps you take the leap from traditional tools to a paradigm shift in DevOps and Modernization.

• Build an enterprise CI/CT/CD pipeline across all your technologies, integrating both vendor and open source tools. Open and modular, ARCAD solutions integrate with all standard DevOps tooling – GitLab, GitHub, BitBucket, Jenkins, Jira, CloudBees, Azure Pipelines and SonarQube to deliver a common DevSecOps pipeline across your entire enterprise and teams. You can also view a demonstration of a simplified CI/CD tool chain in our webinar “DevOps lite”: transition your IBM i development to CI/CD.

• Tune your DevOps pipeline to eliminate bottlenecks in your value stream. ARCAD’s unique metadata repository – a veritable knowledge base built from your own IBM i applications – powers the major Value Stream Management leaders of today –GitLab, HCL, TaskTop, Atlassian, … delivering unique insights into the agility of your DevSecOps flow on IBM i.

Read about the journey made by the Global Head of DevOps Tooling and Engineering Services at HSBC, helping to transition an ‘AS/400 development team’ into an Agile IBM i Pod with a fully automated CI/CT/CD DevOps pipeline in our article Transforming a traditional ‘green screen’ team into an Agile Pod for IBM i.

When it comes to IBM i and the application development lifecycle, it would be easy to stick to the old ways of working. But in today’s world, those old ways just do not cut it. Forward thinking enterprises have massively adopted the Agile and DevOps philosophy. Source control is distributed and tools from the open-source world deliver changes continuously bringing new features to users faster. With all its differences – and its advantages – IBM i belongs in this open-source DevOps world too. However, how can you avoid being stuck in the past and adopt true DevOps on IBM i? Read our article DevOps maturity on IBM i: let go of the past.

Want to understand the key steps to full DevOps maturity and how to devise a roadmap that fits right with your teams? Watch our webinar DevSecOps maturity on IBM i – why is this important? to examine the emerging trends in DevSecOps and explore different routes to maturity.

Identify your level of maturity

All IT processes mature in stages so it’s important to recognize which stage you are at now in order to understand and plan for what’s next. If you rely on a mix of physical servers, inhouse data centers, and cloud technology, then to reach DevOps maturity you will need to standardize on tools able to manage such a hybrid environment. Similarly, if your application contains monolithic code then moving to a modern Web services/microservices architecture will require transformation of the code itself. Applications must be sufficiently modular to avoid slowing DevOps progress.

DevOps maturity models are used to assess the maturity level of DevOps within a company. There are several variations of the model but each one attempts to answer the same question – how mature is DevOps within the organization? To learn more about the different stages of maturity and what the obstacles to DevOps maturity might be, you can read our White papers DevOps Transformation: Engage your IBM i teams and Driving modern DevOps on IBM i.

To achieve this DevOps maturity, you will have two different approaches to choose from:

• The transformative route (fastest) – this route involves a complete plan which plots the fastest path to achieve and maintain mature DevOps on IBM i.
• The progressive route (tools driven) – this route is for organizations whose management believe that the transformative route may be too disruptive.

To avoid costly, high-risk migration projects in the future it is therefore important to act now and start
taking further steps on that IBM i DevOps maturity journey. Looking for tips to optimize your own DevOps implementation and leverage the competitive advantage of your IBM i? Take a look at our guide Modern IBM i DevOps: the “Lucky Seven” tips.

“Coding for the 21st Century” doesn’t mean just changing the way that you develop your user interface – “truly modern” development means adapting to proven coding techniques and DevOps methodology to how you work with your applications. Learn with our webinar Truly Modern CI/CT/CD Development from Code to Deployment how to break away from the being tied to 5250 and print file development by using modern RPG coding techniques.

If you are testing manually, watch our Webinar Continuous Testing (CT) in your DevOps Strategy to learn how to automate the process of Continuous Test, to catch errors as early as possible in the cycle.

Unit Test

On modern, distributed systems, unit testing is arguably the most effective element of your testing strategy. A battery of well-designed unit tests “forces” the quality of your application as it is being developed – and ideally even before. Unit test assets are then re-used continuously right across the lifetime of the application to catch any regressions in the system.

Yet how can unit testing benefit legacy applications on IBM i – and especially those that were not designed with “units” in mind, and where monolithic code has been the norm? Unit testing is an indispensable and often missing link in software development on IBM i. Automated unit testing can make a DevSecOps pipeline on IBM i truly seamless – with measurable benefits in quality, speed and cost:

• Auto-discovery of inputs and outputs to automate the creation of realistic/useful tests
• Integration of unit testing into the version control process
• Auto-execution of tests as continuous part of the CI/CD flow
• Re-use of unit test assets for each program change
• Dependency-driven maintenance/update of unit tests

Want to learn more about unit testing and how it can benefit existing applications on IBM i? Read our article Unit Testing: Beating technical debt.

Regression Test

To avoid the risk of regression and detect defects before they reach production, it is recommended to automate these regression tests for IBM i by recording the functional test cases and automatically replaying them with each application release.

Watch our webinar Automated Testing: How to accelerate and protect your IBM i DevOps pipeline to learn how to safeguard your IBM i application availability, with automated regression test:

• Record test scenarios using an easy-to-use emulator
• Trigger the replay of test scenarios on each commit
• Drive smart dependency-based test campaigns
• Report on defects at their root cause

Test data

Every IT organization does some kind of testing – whether it is unit testing by developers, QA testing by QA staff or full-on automated regression testing. In each of these techniques, one area that is largely underestimated is the role of test data. Yet how effectively this data is managed has a direct impact on the time spent in testing and the quality of the results. By reading our article How to manage test data for smarter, faster testing? you will understand why test data can be hard to manage, what are the best practices based on our experience and which tangible benefits you stand to gain from a consistent set of test data.

Application deployment is undeniably the most critical and high-risk phase in any application development cycle – directly impacting application availability and consequently the continuity of the business.

IBM i apps and database upgrades in sync with distributed systems – on-premises, hybrid and multi-cloud – benefit from being deployed using release management tools to optimize continuous integration and delivery (CI/CD) of IBM i software and data and to manage interdependencies from a single point of control.

The official release of open source tools by IBM has made the IBM i platform “open to all”. ARCAD puts all of its weight behind this movement by supplying the technology needed to achieve a DevOps approach on IBM i. In this way we break the barriers between the so-called “traditional/native” and “modern” development to unify teams and join forces in engaging IT to address the needs of the market. This approach means you can take advantage of the new open source tools for all of your software development. For example, by using Git for source code control across all of your teams, adopting an agile development cycle and one single and unique tool across all platforms, you can rapidly improve knowledge sharing and collaboration within multi-technology projects. Using common processes and tools such as Jenkins for managing the “Build” and the orchestration of deployment, you pave the way to Continuous Integration and Continuous Deployment (CI/CD), and all the benefits in faster, higher quality software delivery that this new model can bring.

Discover how the adoption of Open Source tools can ease development on IBM i by watching our webinar Continuous Integration (CI):
Building a strategy for IBM i using Git, Jenkins and JIRA and how this has helped IBM i become more popular and more accessible to young generations of developers by reading our article Share your IBM i platform with open source tools.

Cloudbees & Jenkins

Jenkins is designed to be distributed, and works best with not just one, but many instances. However, this infrastructure is costly to maintain, and can take away time from not only your IT, but developer time as well. CloudBees Operations Center makes managing multiple Jenkins instances easy with one unified and user-friendly interface. It’s built on Kubernetes, which allows for scalability and elasticity far beyond what’s possible with Jenkins alone, and it’s all ready to go out-of-the-box. This makes it simple to move away from your monolithic pipeline, and into an elastic distributed model. Or, if you’re just starting out with Jenkins, you can be comfortable knowing the solution will scale up with your needs over time. Bottlenecks in your pipeline are costly and can cascade into long-lasting affects. CloudBees is designed remove that possibility.

You may be using Jenkins currently and are wondering what benefits CloudBees could offer you? Or perhaps you have considered using Jenkins, but have some business concerns? To learn more, read our article CI for RPG/COBOL with ARCAD and CloudBees.

Using ARCAD for DevOps guarantees faster delivery and eliminates DevOps complexity. The integration of enterprise tools such as Git, Jenkins and Jira with ARCAD’s IBM i technology layer also gives you the ability to automate a complete end-to-end CI/CT/CD cycle for IBM i.

Deliver on your DevOps objectives with end-to-end workflow automation powered by open source.

Learn how to ensure code quality and security with ARCAD CodeChecker by watching the webinar Drive Code Quality & Security in your IBM i applications and Continuous Quality (CQ): Check the quality of your RPG source code, automatically.

Watch a demonstration of ARCAD iUnit in our webinar on unit testing Unit test automation: Secure application quality on IBM i.

Watch these two webinars to learn more about automated regression testing with ARCAD Verifier Automated Testing: How to accelerate and protect your IBM i DevOps pipeline and discover how ARCAD Verifier pairs nicely with Selenium for this regression testing Pairing Verifier with Selenium for all your Regression Needs.