By Andrew Clark <\/h3>\n<\/div><\/div><\/div>Summary<\/h2>\n\n- Seriously?!?<\/a><\/li>\n
- That’s not possible…<\/a><\/li>\n
- Sounds great \u2013 how do we start?<\/a><\/li>\n<\/ol>\n<\/div><\/div>
So you've probably heard the buzz around two terms in DevOps: Continuous Integration (CI) and Continuous Deployment (CD).\u00a0 You probably also have heard about things like Ansible and Docker and Kubernetes and how they relate to CI\/CD and DevOps and are completely confused about how they apply to the real work that you are doing on your IBM i today.<\/p>\n
The answer is that CI\/CD concepts are<\/u> completely relevant to what you do, but the tooling that you've probably heard about (Ansible\/Docker\/Kubernetes\/etc.) really don't apply (yet!) \u2013 and in fact aren't really necessary because the unique architecture of the IBM i (i.e. integrated database, independent ASP support, ILE) takes care of most of the things those tools do.<\/p>\n
You've probably also already know about all of the supposed goodness of CI\/CD:<\/p>\n
\n- Quicker deployments<\/li>\n
- Fewer errors (and lower cost)<\/li>\n
- Better response to end-users<\/li>\n<\/ul>\n
\u2026but the question remains, how do I get from where I am today to \"real\" DevOps?\u00a0 Maybe nothing that you've seen has given concrete examples of what needs to be done?\u00a0 Here's a good head start:<\/p>\n
CI = automated build and regression testing
\n<\/strong>\u2026if you strip away all the hype, continuous integration is really (conceptually) very simple; when a developer makes a change, all of the necessary related objects are automatically built, and an automated test case runs to ensure that no existing function is broken (that's what \"regression test\" means).\u00a0 If any of the regression test cases fail, then the change is rejected and sent back to the developer to fix.<\/p>\nNotice that automated<\/u> is the key word here \u2013 no human being needs to press keys on their keyboard or click on their mouse to run those tests, it is all handled by a build process that might be as simple as something like a CL program or as sophisticated as something like Jenkins.<\/p>\n
CD = micro-versions
\n<\/strong>\u2026if you strip away all of the hype, Continuous Deployment really just means that when a single functional improvement\/change is complete (a \"micro version\") then that change is pushed to end-users \u00a0immediately<\/u> \u2013 the concept of waiting to bundle lots of changes together into a single \"big bang\" version is obsolete.<\/p>\n<\/div>\n1. Seriously?!?<\/strong><\/h2>\nSeriously.\u00a0 Instead of building \"Version 1.0\" now, and then waiting 3 months to build \"Version 1.1\", and then waiting another year to build \"Version 2.0\" changes get implemented immediately<\/u>.\u00a0 In traditional \"big bang\" versions like this (1.0, 1.1, 2.0 etc.) here's how development reacts to end-users:<\/p>\n
End-user: \"Hey, development, I've got this great idea could you make that change for us?\"<\/p>\n
Development: \"That is a great idea!\u00a0 Should take about two weeks to develop, so we'll try to get it into Version 1.1 at the end of next month, but if we miss that deadline it won't be available until 2.0 next year.\"<\/p>\n
Here's how development reacts to end-users with DevOps:<\/p>\n
Development: \"That is a great idea!\u00a0 Should take about two weeks to develop, and will be ready for you to try out then<\/u>\"<\/p>\n<\/div>\n2. That's not possible\u2026<\/strong><\/h2>\n\u2026actually, it is<\/u> possible, but you might need to make some changes to get there\u2026<\/p>\n\n- Your application must be \"scriptable\"<\/strong>
\nThis is often the most difficult hurdle for implementation of DevOps. By \"scriptable\" we mean that each and every \"function\" of your application must be able to be called by some kind of \"script\" (e.g. CL program) with expected inputs and return expected results.For instance, you might have a \"New order\" function \u2013 you must be able to call that function from a batch<\/u> process (no 5250 i.e. must be runnable from a submitted job) and must be able to return success\/failure based upon various inputs.This means by definition <\/u>that you must have \"business logic\" separated from your \"user interface\" i.e. your single interactive RPG order entry menu-driven 10,000 lines-of-code program is not going to cut it\u2026<\/li>\n- You have to have a real test script<\/strong>
\nTesting is said to be a pillar of DevOps because delivering \"faster and more often\" means accepting the risk of frequent updates in production. Continuous testing offsets this risk.
\nThe sad truth is that many companies don't have any kind of test script in place, whether it just be a simple document or some existing automated test process \u2013 when a new version is generated, it's released to a QA team and they may run through some kind of manual process or might just randomly test a few of the major functions of the application to make sure that they work \u2013 that's not going to cut it either\u2026<\/li>\n<\/ol>\nThere is much scope for automating this part of the process.\u00a0 Once you're in the habit of of creating specific test scripts for each new function you want to deliver, you can go one step further and automate the \"unit\" testing of your new code. There are tools out there that understand your application code and help you create your unit tests so you can re-use them for \"smoke\" testing later (check out ARCAD iUnit<\/a>).\u00a0 The goal of course being to catch defects even before they are deployed to QA for regression testing\u2026<\/p>\nThen once in QA, the IBM i regression testing tools (like ARCAD Verifier<\/a>) can trigger functional tests to run over your ready-to-deliver IBM i application to give you a final safeguard before your code reaches production.<\/p>\nOnce you've reached this level of automation, you're already well on your way to achieving a \"continuous test\" (CT) approach to development\u2026<\/p>\n<\/div><\/div><\/div>
Implementing a DevOps strategy on IBM i? Influencing IBM i DevOps maturity and success in the enterprise?<\/strong><\/p>\n<\/div>Download our White Paper <\/span><\/i><\/a><\/div><\/div><\/div><\/div><\/div><\/div>\n3. Sounds great \u2013 how do we start?<\/strong><\/h2>\nIf your application is RPG or COBOL, then probably start here ([White Paper] DevOps Transformation: Engage your IBM i teams<\/a><\/em>) and then:<\/p>\n\n- Lay the Foundation<\/strong>\n
\n- Analyze your existing resources\n
\n- Skillset, methodology, existing tooling<\/em><\/li>\n
- Identify “Champions”<\/em><\/li>\n<\/ul>\n<\/li>\n
- Pick DevOps tools that match your needs and experience\n
\n- …not necessarily those that have the largest visibility<\/em><\/li>\n
- \u2026seriously consider sharing common DevOps tools with developers on distributed systems (e.g. Git, Jenkins, Jira, Azure DevOps), to achieve a common DevOps toolchain enterprise-wide<\/em><\/li>\n
- \u2026remember that open source tools alone<\/u> don\u2019t cut it on IBM i – so look for an IBM i DevOps vendor that offers ready-made integrations to make the adoption of open source easier<\/em><\/li>\n<\/ul>\n<\/li>\n
- Document your existing application (files\/fields\/programs by function, type, etc.)<\/li>\n
- Conceptualize what “functions” need to be tested<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
\n- Make incremental Development changes<\/strong>\n
\n- Implement source control (e.g. Git)<\/li>\n
- Start using RDi (if you aren’t already)<\/li>\n
- Break up monolithic programs into modules and procedures\n
\n- First step \u2013 convert RPGIII->ILE (if you haven’t already!?!)<\/em><\/li>\n<\/ul>\n<\/li>\n
- Separate business logic from user interface (aka MVC)<\/li>\n
- Write actual test scripts OR<\/li>\n
- Use an IBM i unit testing tool<\/a> to create re-usable program and procedure tests<\/li>\n
- Automate your functional regression testing<\/a> using Jenkins as driver<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
Summary<\/h2>\n\n- Seriously?!?<\/a><\/li>\n
- That’s not possible…<\/a><\/li>\n
- Sounds great \u2013 how do we start?<\/a><\/li>\n<\/ol>\n<\/div><\/div>
So you've probably heard the buzz around two terms in DevOps: Continuous Integration (CI) and Continuous Deployment (CD).\u00a0 You probably also have heard about things like Ansible and Docker and Kubernetes and how they relate to CI\/CD and DevOps and are completely confused about how they apply to the real work that you are doing on your IBM i today.<\/p>\n
The answer is that CI\/CD concepts are<\/u> completely relevant to what you do, but the tooling that you've probably heard about (Ansible\/Docker\/Kubernetes\/etc.) really don't apply (yet!) \u2013 and in fact aren't really necessary because the unique architecture of the IBM i (i.e. integrated database, independent ASP support, ILE) takes care of most of the things those tools do.<\/p>\n
You've probably also already know about all of the supposed goodness of CI\/CD:<\/p>\n
\n- Quicker deployments<\/li>\n
- Fewer errors (and lower cost)<\/li>\n
- Better response to end-users<\/li>\n<\/ul>\n
\u2026but the question remains, how do I get from where I am today to \"real\" DevOps?\u00a0 Maybe nothing that you've seen has given concrete examples of what needs to be done?\u00a0 Here's a good head start:<\/p>\n
CI = automated build and regression testing
\n<\/strong>\u2026if you strip away all the hype, continuous integration is really (conceptually) very simple; when a developer makes a change, all of the necessary related objects are automatically built, and an automated test case runs to ensure that no existing function is broken (that's what \"regression test\" means).\u00a0 If any of the regression test cases fail, then the change is rejected and sent back to the developer to fix.<\/p>\nNotice that automated<\/u> is the key word here \u2013 no human being needs to press keys on their keyboard or click on their mouse to run those tests, it is all handled by a build process that might be as simple as something like a CL program or as sophisticated as something like Jenkins.<\/p>\n
CD = micro-versions
\n<\/strong>\u2026if you strip away all of the hype, Continuous Deployment really just means that when a single functional improvement\/change is complete (a \"micro version\") then that change is pushed to end-users \u00a0immediately<\/u> \u2013 the concept of waiting to bundle lots of changes together into a single \"big bang\" version is obsolete.<\/p>\n<\/div>\n1. Seriously?!?<\/strong><\/h2>\nSeriously.\u00a0 Instead of building \"Version 1.0\" now, and then waiting 3 months to build \"Version 1.1\", and then waiting another year to build \"Version 2.0\" changes get implemented immediately<\/u>.\u00a0 In traditional \"big bang\" versions like this (1.0, 1.1, 2.0 etc.) here's how development reacts to end-users:<\/p>\n
End-user: \"Hey, development, I've got this great idea could you make that change for us?\"<\/p>\n
Development: \"That is a great idea!\u00a0 Should take about two weeks to develop, so we'll try to get it into Version 1.1 at the end of next month, but if we miss that deadline it won't be available until 2.0 next year.\"<\/p>\n
Here's how development reacts to end-users with DevOps:<\/p>\n
Development: \"That is a great idea!\u00a0 Should take about two weeks to develop, and will be ready for you to try out then<\/u>\"<\/p>\n<\/div>\n2. That's not possible\u2026<\/strong><\/h2>\n\u2026actually, it is<\/u> possible, but you might need to make some changes to get there\u2026<\/p>\n\n- Your application must be \"scriptable\"<\/strong>
\nThis is often the most difficult hurdle for implementation of DevOps. By \"scriptable\" we mean that each and every \"function\" of your application must be able to be called by some kind of \"script\" (e.g. CL program) with expected inputs and return expected results.For instance, you might have a \"New order\" function \u2013 you must be able to call that function from a batch<\/u> process (no 5250 i.e. must be runnable from a submitted job) and must be able to return success\/failure based upon various inputs.This means by definition <\/u>that you must have \"business logic\" separated from your \"user interface\" i.e. your single interactive RPG order entry menu-driven 10,000 lines-of-code program is not going to cut it\u2026<\/li>\n- You have to have a real test script<\/strong>
\nTesting is said to be a pillar of DevOps because delivering \"faster and more often\" means accepting the risk of frequent updates in production. Continuous testing offsets this risk.
\nThe sad truth is that many companies don't have any kind of test script in place, whether it just be a simple document or some existing automated test process \u2013 when a new version is generated, it's released to a QA team and they may run through some kind of manual process or might just randomly test a few of the major functions of the application to make sure that they work \u2013 that's not going to cut it either\u2026<\/li>\n<\/ol>\nThere is much scope for automating this part of the process.\u00a0 Once you're in the habit of of creating specific test scripts for each new function you want to deliver, you can go one step further and automate the \"unit\" testing of your new code. There are tools out there that understand your application code and help you create your unit tests so you can re-use them for \"smoke\" testing later (check out ARCAD iUnit<\/a>).\u00a0 The goal of course being to catch defects even before they are deployed to QA for regression testing\u2026<\/p>\nThen once in QA, the IBM i regression testing tools (like ARCAD Verifier<\/a>) can trigger functional tests to run over your ready-to-deliver IBM i application to give you a final safeguard before your code reaches production.<\/p>\nOnce you've reached this level of automation, you're already well on your way to achieving a \"continuous test\" (CT) approach to development\u2026<\/p>\n<\/div><\/div><\/div>
Implementing a DevOps strategy on IBM i? Influencing IBM i DevOps maturity and success in the enterprise?<\/strong><\/p>\n<\/div>Download our White Paper <\/span><\/i><\/a><\/div><\/div><\/div><\/div><\/div><\/div>\n3. Sounds great \u2013 how do we start?<\/strong><\/h2>\nIf your application is RPG or COBOL, then probably start here ([White Paper] DevOps Transformation: Engage your IBM i teams<\/a><\/em>) and then:<\/p>\n\n- Lay the Foundation<\/strong>\n
\n- Analyze your existing resources\n
\n- Skillset, methodology, existing tooling<\/em><\/li>\n
- Identify “Champions”<\/em><\/li>\n<\/ul>\n<\/li>\n
- Pick DevOps tools that match your needs and experience\n
\n- …not necessarily those that have the largest visibility<\/em><\/li>\n
- \u2026seriously consider sharing common DevOps tools with developers on distributed systems (e.g. Git, Jenkins, Jira, Azure DevOps), to achieve a common DevOps toolchain enterprise-wide<\/em><\/li>\n
- \u2026remember that open source tools alone<\/u> don\u2019t cut it on IBM i – so look for an IBM i DevOps vendor that offers ready-made integrations to make the adoption of open source easier<\/em><\/li>\n<\/ul>\n<\/li>\n
- Document your existing application (files\/fields\/programs by function, type, etc.)<\/li>\n
- Conceptualize what “functions” need to be tested<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
\n- Make incremental Development changes<\/strong>\n
\n- Implement source control (e.g. Git)<\/li>\n
- Start using RDi (if you aren’t already)<\/li>\n
- Break up monolithic programs into modules and procedures\n
\n- First step \u2013 convert RPGIII->ILE (if you haven’t already!?!)<\/em><\/li>\n<\/ul>\n<\/li>\n
- Separate business logic from user interface (aka MVC)<\/li>\n
- Write actual test scripts OR<\/li>\n
- Use an IBM i unit testing tool<\/a> to create re-usable program and procedure tests<\/li>\n
- Automate your functional regression testing<\/a> using Jenkins as driver<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
So you've probably heard the buzz around two terms in DevOps: Continuous Integration (CI) and Continuous Deployment (CD).\u00a0 You probably also have heard about things like Ansible and Docker and Kubernetes and how they relate to CI\/CD and DevOps and are completely confused about how they apply to the real work that you are doing on your IBM i today.<\/p>\n
The answer is that CI\/CD concepts are<\/u> completely relevant to what you do, but the tooling that you've probably heard about (Ansible\/Docker\/Kubernetes\/etc.) really don't apply (yet!) \u2013 and in fact aren't really necessary because the unique architecture of the IBM i (i.e. integrated database, independent ASP support, ILE) takes care of most of the things those tools do.<\/p>\n
You've probably also already know about all of the supposed goodness of CI\/CD:<\/p>\n
- \n
- Quicker deployments<\/li>\n
- Fewer errors (and lower cost)<\/li>\n
- Better response to end-users<\/li>\n<\/ul>\n
\u2026but the question remains, how do I get from where I am today to \"real\" DevOps?\u00a0 Maybe nothing that you've seen has given concrete examples of what needs to be done?\u00a0 Here's a good head start:<\/p>\n
CI = automated build and regression testing
\n<\/strong>\u2026if you strip away all the hype, continuous integration is really (conceptually) very simple; when a developer makes a change, all of the necessary related objects are automatically built, and an automated test case runs to ensure that no existing function is broken (that's what \"regression test\" means).\u00a0 If any of the regression test cases fail, then the change is rejected and sent back to the developer to fix.<\/p>\nNotice that automated<\/u> is the key word here \u2013 no human being needs to press keys on their keyboard or click on their mouse to run those tests, it is all handled by a build process that might be as simple as something like a CL program or as sophisticated as something like Jenkins.<\/p>\n
CD = micro-versions
\n<\/strong>\u2026if you strip away all of the hype, Continuous Deployment really just means that when a single functional improvement\/change is complete (a \"micro version\") then that change is pushed to end-users \u00a0immediately<\/u> \u2013 the concept of waiting to bundle lots of changes together into a single \"big bang\" version is obsolete.<\/p>\n<\/div>\n1. Seriously?!?<\/strong><\/h2>\n
Seriously.\u00a0 Instead of building \"Version 1.0\" now, and then waiting 3 months to build \"Version 1.1\", and then waiting another year to build \"Version 2.0\" changes get implemented immediately<\/u>.\u00a0 In traditional \"big bang\" versions like this (1.0, 1.1, 2.0 etc.) here's how development reacts to end-users:<\/p>\n
End-user: \"Hey, development, I've got this great idea could you make that change for us?\"<\/p>\n
Development: \"That is a great idea!\u00a0 Should take about two weeks to develop, so we'll try to get it into Version 1.1 at the end of next month, but if we miss that deadline it won't be available until 2.0 next year.\"<\/p>\n
Here's how development reacts to end-users with DevOps:<\/p>\n
Development: \"That is a great idea!\u00a0 Should take about two weeks to develop, and will be ready for you to try out then<\/u>\"<\/p>\n
<\/div>\n2. That's not possible\u2026<\/strong><\/h2>\n
\u2026actually, it is<\/u> possible, but you might need to make some changes to get there\u2026<\/p>\n
- \n
- Your application must be \"scriptable\"<\/strong>
\nThis is often the most difficult hurdle for implementation of DevOps. By \"scriptable\" we mean that each and every \"function\" of your application must be able to be called by some kind of \"script\" (e.g. CL program) with expected inputs and return expected results.For instance, you might have a \"New order\" function \u2013 you must be able to call that function from a batch<\/u> process (no 5250 i.e. must be runnable from a submitted job) and must be able to return success\/failure based upon various inputs.This means by definition <\/u>that you must have \"business logic\" separated from your \"user interface\" i.e. your single interactive RPG order entry menu-driven 10,000 lines-of-code program is not going to cut it\u2026<\/li>\n- You have to have a real test script<\/strong>
\nTesting is said to be a pillar of DevOps because delivering \"faster and more often\" means accepting the risk of frequent updates in production. Continuous testing offsets this risk.
\nThe sad truth is that many companies don't have any kind of test script in place, whether it just be a simple document or some existing automated test process \u2013 when a new version is generated, it's released to a QA team and they may run through some kind of manual process or might just randomly test a few of the major functions of the application to make sure that they work \u2013 that's not going to cut it either\u2026<\/li>\n<\/ol>\nThere is much scope for automating this part of the process.\u00a0 Once you're in the habit of of creating specific test scripts for each new function you want to deliver, you can go one step further and automate the \"unit\" testing of your new code. There are tools out there that understand your application code and help you create your unit tests so you can re-use them for \"smoke\" testing later (check out ARCAD iUnit<\/a>).\u00a0 The goal of course being to catch defects even before they are deployed to QA for regression testing\u2026<\/p>\n
Then once in QA, the IBM i regression testing tools (like ARCAD Verifier<\/a>) can trigger functional tests to run over your ready-to-deliver IBM i application to give you a final safeguard before your code reaches production.<\/p>\n
Once you've reached this level of automation, you're already well on your way to achieving a \"continuous test\" (CT) approach to development\u2026<\/p>\n<\/div><\/div><\/div>
Implementing a DevOps strategy on IBM i? Influencing IBM i DevOps maturity and success in the enterprise?<\/strong><\/p>\n<\/div>
Download our White Paper <\/span><\/i><\/a><\/div><\/div><\/div><\/div><\/div><\/div>\n3. Sounds great \u2013 how do we start?<\/strong><\/h2>\n
If your application is RPG or COBOL, then probably start here ([White Paper] DevOps Transformation: Engage your IBM i teams<\/a><\/em>) and then:<\/p>\n
- \n
- Lay the Foundation<\/strong>\n
- \n
- Analyze your existing resources\n
- \n
- Skillset, methodology, existing tooling<\/em><\/li>\n
- Identify “Champions”<\/em><\/li>\n<\/ul>\n<\/li>\n
- Pick DevOps tools that match your needs and experience\n
- \n
- …not necessarily those that have the largest visibility<\/em><\/li>\n
- \u2026seriously consider sharing common DevOps tools with developers on distributed systems (e.g. Git, Jenkins, Jira, Azure DevOps), to achieve a common DevOps toolchain enterprise-wide<\/em><\/li>\n
- \u2026remember that open source tools alone<\/u> don\u2019t cut it on IBM i – so look for an IBM i DevOps vendor that offers ready-made integrations to make the adoption of open source easier<\/em><\/li>\n<\/ul>\n<\/li>\n
- Document your existing application (files\/fields\/programs by function, type, etc.)<\/li>\n
- Conceptualize what “functions” need to be tested<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
- \n
- Make incremental Development changes<\/strong>\n
- \n
- Implement source control (e.g. Git)<\/li>\n
- Start using RDi (if you aren’t already)<\/li>\n
- Break up monolithic programs into modules and procedures\n
- \n
- First step \u2013 convert RPGIII->ILE (if you haven’t already!?!)<\/em><\/li>\n<\/ul>\n<\/li>\n
- Separate business logic from user interface (aka MVC)<\/li>\n
- Write actual test scripts OR<\/li>\n
- Use an IBM i unit testing tool<\/a> to create re-usable program and procedure tests<\/li>\n
- Automate your functional regression testing<\/a> using Jenkins as driver<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
- First step \u2013 convert RPGIII->ILE (if you haven’t already!?!)<\/em><\/li>\n<\/ul>\n<\/li>\n
- \u2026seriously consider sharing common DevOps tools with developers on distributed systems (e.g. Git, Jenkins, Jira, Azure DevOps), to achieve a common DevOps toolchain enterprise-wide<\/em><\/li>\n
- Identify “Champions”<\/em><\/li>\n<\/ul>\n<\/li>\n
- Skillset, methodology, existing tooling<\/em><\/li>\n
- Analyze your existing resources\n
- You have to have a real test script<\/strong>
- Your application must be \"scriptable\"<\/strong>
![\"Andrew](\"https:\/\/www.arcadsoftware.com\/arcad\/wp-content\/uploads\/2019\/09\/andrew-clark-picture.jpg\")
<\/p>\n<\/div><\/div><\/div>