By Alan Ashley <\/h3>\n<\/div><\/div><\/div>When speaking of the IBM i and the lifecycle of application development, it would be easy to stick to the old ways of working. But in today\u2019s 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. I will argue that with all its differences \u2013 and its advantages – IBM i belongs in this open-source DevOps world too. The risk of staying put is just too great.<\/p>\n
Today, I\u2019ll cover the following:<\/p>\n<\/div>
Summary<\/h2>\n\n- A Little about my perspective<\/a><\/li>\n
- The ARCAD workflow<\/a><\/li>\n
- Automation and \u2018shift left\u2019<\/a><\/li>\n
- Open-source tools on IBM i<\/a><\/li>\n
- Git on IBM i<\/a><\/li>\n
- Next steps<\/a><\/li>\n<\/ol>\n<\/div><\/div>\n
1. My perspective (keeping IBM i applications up and running)<\/h2>\n
To start, I grew up on green screen while supporting customers across the spectrum for more than 30 years. I have seen the pain of controlling the source code, testing the code, and fixing the bugs in production. I cannot count how many times I was called at 2am to fix a level check error in production. While the IBM i has changed a lot over the years, growing up from the AS\/400 through the iSeries years to where we are today, one thing stayed constant during this time. The pain of moving through the Development to Production process.<\/p>\n
When I joined ARCAD Software earlier this year, I had the chance to dive into the suite of tools available. My first thought was, I can think of a dozen former customers that could benefit from just a part of this suite. ARCAD starts with the analysis and audit of your code, and this alone is a game changer. How many times have you wondered if you are working off the correct source? This analysis aids in cleaning your development environment, which is especially important when moving into the future of DevOps and the use of open-source tools. But the ARCAD tools don\u2019t stop there. The application knowledge \u2013 or metadata – that is derived from this initial analysis phase is re-used across the entire end-to-end CI\/CT\/CD cycle making each of the downstream ARCAD tools smarter and faster. More about that later\u2026<\/p>\n
My perspective on code development is a bit different as I am not a developer. I was an admin for most of my career, and my coding skills focused on code that would make my life easier or help me debug 2AM errors. In my duties, I usually had to start with hunting the source code. The DSPPGM command was my friend along with DSPDBR. What I have found with the ARCAD products, they take away the need to do that level of hunting. Why? Because it will not let the developer push to production without a few dozen checks along the way. Here is how this works\u2026<\/p>\n
<\/div>\n2. The ARCAD workflow: nothing is wasted<\/h2>\n
Lifecycle and Source Code Management are at the heart of what ARCAD brings to the table. You can see in the diagram below how it can touch and assist in each area of the CI\/CT\/CD flow. ARCAD manages the entire versioning process either with Git or natively as you prefer. Then as you check-out, edit and compile your source code directly from LPEX, you can right-click on any text field, file, procedure, program, data area, or even literals to see everywhere that construct is used which is a great time saver. Then, ARCAD will analyze your source code to highlight any areas that break quality or security rules. Once you are done and you commit your change, a build is automatically launched, compiling any impacted dependent code. No more manual sequencing of compiles! ARCAD optimizes the build to compile only what is needed and in the right order. After the build, then unit tests and functional regression tests are executed for you in a continuous flow. Once the release is validated, it is deployed automatically to production, with a rollback on error.<\/p>\n<\/div>
![\"Lifecycle](\"https:\/\/www.arcadsoftware.com\/arcad\/wp-content\/uploads\/2021\/08\/lifecycle-and-source-code-management.png\" "\\"Lifecycle")
<\/span><\/div>With all this automation, the developer only needs to worry about writing code<\/u><\/em>.<\/b> All those pain points from where is my source, who tested this and why was the defect not found, to controlling the roll out of code across not only your IBM i Environment but your Open and Distributed systems are all taken care of.<\/p>\n<\/div><\/div><\/div>BWI companies switches from in-house change management to automated Git & Jira on IBM i using ARCAD for DevOps.<\/strong><\/p>\n<\/div>Read the case study<\/span><\/i><\/a><\/div><\/div><\/div><\/div><\/div><\/div>\n3. Automation and \u2018shift left\u2019<\/h2>\n
Wait, am I saying the developer will have to go through a checklist to push the change to production or even just to the UAT environment? No, that is the great thing with ARCAD, all is handled behind the scenes. If you update the format of a file, it will find all the programs and objects that need to be recompiled. So, no more Level Check errors. If the file changed involves a dozen other screens, programs, files, or menus, those are all known thanks to the repository created at the install and those objects recompiled as needed. Now the developer can focus on the code rather than the \u2018what ifs\u2019. This is a great time saver or moreover a great money saver to your company. All part of the \u2018Shift Left\u2019 mentality. When you hear Shift Left, the first thing you should think of is, the cost of creating code and moving it into production. The closer to production defects are found, the more expensive the fix. So, \u2018shifting left\u2019 massively lowers the cost of a defect fix.<\/p>\n<\/div>
![\"Automation](\"https:\/\/www.arcadsoftware.com\/arcad\/wp-content\/uploads\/2021\/08\/auomation-and-shift-left-600x314.jpg\" "\\"Automation")
<\/span><\/div><\/div>\n4. Open source tools on IBM i<\/h2>\n
So now you\u2019ll hear scary terms as you embrace DevOps on IBM i like Jira<\/a>, Git<\/a>, Jenkins<\/a>. You\u2019ll hear things like Pipelines and Branches. But don\u2019t worry, I have found that the Arcad Software Suite<\/a> makes this painless. As I said before, I\u2019m not a developer, but to learn the basics to make and promote code in a DevOps environment was made easy with ARCAD. So let go of the old way of thinking with SEU and PDM, embrace RDi, Open Source, SCM, Git, Jenkins and Pipelines, because ARCAD will be there to guide you through the CI\/CT\/CD process. ARCAD is at the center of this universe and driving the movement forward.<\/p>\n<\/div>![\"ARCAD](\"https:\/\/www.arcadsoftware.com\/arcad\/wp-content\/uploads\/2021\/06\/arcad-integration-600x492.jpg\" "\\"arcad-integration\\"")
<\/span><\/div>At this point, you are thinking, what does this have to do with letting go of the past? This just seems like more work instead. Well as you probably know by now, we are all knee deep in the DevOps\/Agile philosophy which applies equally well to IBM i as to any technology platform. You will see from the case studies below that we have rapidly rolled out DevOps on IBM i with Git and open source tools in some of the most traditional IBM i development teams. Because the ARCAD layer makes the Git interface totally transparent, even the most senior IBM i developers are happily branching from the same Git repo and CI\/CD pipeline as their (probably younger) peers developing on Windows or Linux!<\/p>\n<\/div><\/div><\/div>
Join the BWI team\u202fand ARCAD Software\u202fto learn key tips and techniques for\u202fyour\u202fsuccessful move to Git on IBM\u202fi.<\/strong><\/p>\n<\/div>
When speaking of the IBM i and the lifecycle of application development, it would be easy to stick to the old ways of working. But in today\u2019s 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. I will argue that with all its differences \u2013 and its advantages – IBM i belongs in this open-source DevOps world too. The risk of staying put is just too great.<\/p>\n
Today, I\u2019ll cover the following:<\/p>\n<\/div>
Summary<\/h2>\n\n- A Little about my perspective<\/a><\/li>\n
- The ARCAD workflow<\/a><\/li>\n
- Automation and \u2018shift left\u2019<\/a><\/li>\n
- Open-source tools on IBM i<\/a><\/li>\n
- Git on IBM i<\/a><\/li>\n
- Next steps<\/a><\/li>\n<\/ol>\n<\/div><\/div>\n
1. My perspective (keeping IBM i applications up and running)<\/h2>\n
To start, I grew up on green screen while supporting customers across the spectrum for more than 30 years. I have seen the pain of controlling the source code, testing the code, and fixing the bugs in production. I cannot count how many times I was called at 2am to fix a level check error in production. While the IBM i has changed a lot over the years, growing up from the AS\/400 through the iSeries years to where we are today, one thing stayed constant during this time. The pain of moving through the Development to Production process.<\/p>\n
When I joined ARCAD Software earlier this year, I had the chance to dive into the suite of tools available. My first thought was, I can think of a dozen former customers that could benefit from just a part of this suite. ARCAD starts with the analysis and audit of your code, and this alone is a game changer. How many times have you wondered if you are working off the correct source? This analysis aids in cleaning your development environment, which is especially important when moving into the future of DevOps and the use of open-source tools. But the ARCAD tools don\u2019t stop there. The application knowledge \u2013 or metadata – that is derived from this initial analysis phase is re-used across the entire end-to-end CI\/CT\/CD cycle making each of the downstream ARCAD tools smarter and faster. More about that later\u2026<\/p>\n
My perspective on code development is a bit different as I am not a developer. I was an admin for most of my career, and my coding skills focused on code that would make my life easier or help me debug 2AM errors. In my duties, I usually had to start with hunting the source code. The DSPPGM command was my friend along with DSPDBR. What I have found with the ARCAD products, they take away the need to do that level of hunting. Why? Because it will not let the developer push to production without a few dozen checks along the way. Here is how this works\u2026<\/p>\n
<\/div>\n2. The ARCAD workflow: nothing is wasted<\/h2>\n
Lifecycle and Source Code Management are at the heart of what ARCAD brings to the table. You can see in the diagram below how it can touch and assist in each area of the CI\/CT\/CD flow. ARCAD manages the entire versioning process either with Git or natively as you prefer. Then as you check-out, edit and compile your source code directly from LPEX, you can right-click on any text field, file, procedure, program, data area, or even literals to see everywhere that construct is used which is a great time saver. Then, ARCAD will analyze your source code to highlight any areas that break quality or security rules. Once you are done and you commit your change, a build is automatically launched, compiling any impacted dependent code. No more manual sequencing of compiles! ARCAD optimizes the build to compile only what is needed and in the right order. After the build, then unit tests and functional regression tests are executed for you in a continuous flow. Once the release is validated, it is deployed automatically to production, with a rollback on error.<\/p>\n<\/div>
<\/span><\/div>With all this automation, the developer only needs to worry about writing code<\/u><\/em>.<\/b> All those pain points from where is my source, who tested this and why was the defect not found, to controlling the roll out of code across not only your IBM i Environment but your Open and Distributed systems are all taken care of.<\/p>\n<\/div><\/div><\/div>BWI companies switches from in-house change management to automated Git & Jira on IBM i using ARCAD for DevOps.<\/strong><\/p>\n<\/div>Read the case study<\/span><\/i><\/a><\/div><\/div><\/div><\/div><\/div><\/div>\n3. Automation and \u2018shift left\u2019<\/h2>\n
Wait, am I saying the developer will have to go through a checklist to push the change to production or even just to the UAT environment? No, that is the great thing with ARCAD, all is handled behind the scenes. If you update the format of a file, it will find all the programs and objects that need to be recompiled. So, no more Level Check errors. If the file changed involves a dozen other screens, programs, files, or menus, those are all known thanks to the repository created at the install and those objects recompiled as needed. Now the developer can focus on the code rather than the \u2018what ifs\u2019. This is a great time saver or moreover a great money saver to your company. All part of the \u2018Shift Left\u2019 mentality. When you hear Shift Left, the first thing you should think of is, the cost of creating code and moving it into production. The closer to production defects are found, the more expensive the fix. So, \u2018shifting left\u2019 massively lowers the cost of a defect fix.<\/p>\n<\/div>
<\/span><\/div><\/div>\n4. Open source tools on IBM i<\/h2>\n
So now you\u2019ll hear scary terms as you embrace DevOps on IBM i like Jira<\/a>, Git<\/a>, Jenkins<\/a>. You\u2019ll hear things like Pipelines and Branches. But don\u2019t worry, I have found that the Arcad Software Suite<\/a> makes this painless. As I said before, I\u2019m not a developer, but to learn the basics to make and promote code in a DevOps environment was made easy with ARCAD. So let go of the old way of thinking with SEU and PDM, embrace RDi, Open Source, SCM, Git, Jenkins and Pipelines, because ARCAD will be there to guide you through the CI\/CT\/CD process. ARCAD is at the center of this universe and driving the movement forward.<\/p>\n<\/div><\/span><\/div>At this point, you are thinking, what does this have to do with letting go of the past? This just seems like more work instead. Well as you probably know by now, we are all knee deep in the DevOps\/Agile philosophy which applies equally well to IBM i as to any technology platform. You will see from the case studies below that we have rapidly rolled out DevOps on IBM i with Git and open source tools in some of the most traditional IBM i development teams. Because the ARCAD layer makes the Git interface totally transparent, even the most senior IBM i developers are happily branching from the same Git repo and CI\/CD pipeline as their (probably younger) peers developing on Windows or Linux!<\/p>\n<\/div><\/div><\/div>
Join the BWI team\u202fand ARCAD Software\u202fto learn key tips and techniques for\u202fyour\u202fsuccessful move to Git on IBM\u202fi.<\/strong><\/p>\n<\/div>
1. My perspective (keeping IBM i applications up and running)<\/h2>\n
To start, I grew up on green screen while supporting customers across the spectrum for more than 30 years. I have seen the pain of controlling the source code, testing the code, and fixing the bugs in production. I cannot count how many times I was called at 2am to fix a level check error in production. While the IBM i has changed a lot over the years, growing up from the AS\/400 through the iSeries years to where we are today, one thing stayed constant during this time. The pain of moving through the Development to Production process.<\/p>\n
When I joined ARCAD Software earlier this year, I had the chance to dive into the suite of tools available. My first thought was, I can think of a dozen former customers that could benefit from just a part of this suite. ARCAD starts with the analysis and audit of your code, and this alone is a game changer. How many times have you wondered if you are working off the correct source? This analysis aids in cleaning your development environment, which is especially important when moving into the future of DevOps and the use of open-source tools. But the ARCAD tools don\u2019t stop there. The application knowledge \u2013 or metadata – that is derived from this initial analysis phase is re-used across the entire end-to-end CI\/CT\/CD cycle making each of the downstream ARCAD tools smarter and faster. More about that later\u2026<\/p>\n
My perspective on code development is a bit different as I am not a developer. I was an admin for most of my career, and my coding skills focused on code that would make my life easier or help me debug 2AM errors. In my duties, I usually had to start with hunting the source code. The DSPPGM command was my friend along with DSPDBR. What I have found with the ARCAD products, they take away the need to do that level of hunting. Why? Because it will not let the developer push to production without a few dozen checks along the way. Here is how this works\u2026<\/p>\n
2. The ARCAD workflow: nothing is wasted<\/h2>\n
Lifecycle and Source Code Management are at the heart of what ARCAD brings to the table. You can see in the diagram below how it can touch and assist in each area of the CI\/CT\/CD flow. ARCAD manages the entire versioning process either with Git or natively as you prefer. Then as you check-out, edit and compile your source code directly from LPEX, you can right-click on any text field, file, procedure, program, data area, or even literals to see everywhere that construct is used which is a great time saver. Then, ARCAD will analyze your source code to highlight any areas that break quality or security rules. Once you are done and you commit your change, a build is automatically launched, compiling any impacted dependent code. No more manual sequencing of compiles! ARCAD optimizes the build to compile only what is needed and in the right order. After the build, then unit tests and functional regression tests are executed for you in a continuous flow. Once the release is validated, it is deployed automatically to production, with a rollback on error.<\/p>\n<\/div>
<\/span><\/div>With all this automation, the developer only needs to worry about writing code<\/u><\/em>.<\/b> All those pain points from where is my source, who tested this and why was the defect not found, to controlling the roll out of code across not only your IBM i Environment but your Open and Distributed systems are all taken care of.<\/p>\n<\/div><\/div><\/div> BWI companies switches from in-house change management to automated Git & Jira on IBM i using ARCAD for DevOps.<\/strong><\/p>\n<\/div> Wait, am I saying the developer will have to go through a checklist to push the change to production or even just to the UAT environment? No, that is the great thing with ARCAD, all is handled behind the scenes. If you update the format of a file, it will find all the programs and objects that need to be recompiled. So, no more Level Check errors. If the file changed involves a dozen other screens, programs, files, or menus, those are all known thanks to the repository created at the install and those objects recompiled as needed. Now the developer can focus on the code rather than the \u2018what ifs\u2019. This is a great time saver or moreover a great money saver to your company. All part of the \u2018Shift Left\u2019 mentality. When you hear Shift Left, the first thing you should think of is, the cost of creating code and moving it into production. The closer to production defects are found, the more expensive the fix. So, \u2018shifting left\u2019 massively lowers the cost of a defect fix.<\/p>\n<\/div> So now you\u2019ll hear scary terms as you embrace DevOps on IBM i like Jira<\/a>, Git<\/a>, Jenkins<\/a>. You\u2019ll hear things like Pipelines and Branches. But don\u2019t worry, I have found that the Arcad Software Suite<\/a> makes this painless. As I said before, I\u2019m not a developer, but to learn the basics to make and promote code in a DevOps environment was made easy with ARCAD. So let go of the old way of thinking with SEU and PDM, embrace RDi, Open Source, SCM, Git, Jenkins and Pipelines, because ARCAD will be there to guide you through the CI\/CT\/CD process. ARCAD is at the center of this universe and driving the movement forward.<\/p>\n<\/div> At this point, you are thinking, what does this have to do with letting go of the past? This just seems like more work instead. Well as you probably know by now, we are all knee deep in the DevOps\/Agile philosophy which applies equally well to IBM i as to any technology platform. You will see from the case studies below that we have rapidly rolled out DevOps on IBM i with Git and open source tools in some of the most traditional IBM i development teams. Because the ARCAD layer makes the Git interface totally transparent, even the most senior IBM i developers are happily branching from the same Git repo and CI\/CD pipeline as their (probably younger) peers developing on Windows or Linux!<\/p>\n<\/div><\/div><\/div> Join the BWI team\u202fand ARCAD Software\u202fto learn key tips and techniques for\u202fyour\u202fsuccessful move to Git on IBM\u202fi.<\/strong><\/p>\n<\/div>3. Automation and \u2018shift left\u2019<\/h2>\n
<\/span><\/div>4. Open source tools on IBM i<\/h2>\n
<\/span><\/div>
![\"RDI](\"https:\/\/www.arcadsoftware.com\/arcad\/wp-content\/uploads\/2021\/08\/rdi-or-green-screen-600x166.jpg\" "\\"RDI")
<\/span><\/div>![\"Philippe](\"https:\/\/www.arcadsoftware.com\/arcad\/wp-content\/uploads\/2021\/07\/alan-ashley-2-150x150.png\" "\\"Alan")
<\/span><\/div><\/div><\/div>