{"id":2568,"date":"2021-02-18T17:10:08","date_gmt":"2021-02-18T22:10:08","guid":{"rendered":"https:\/\/blogs.mathworks.com\/developer\/?p=2568"},"modified":"2021-02-18T17:30:19","modified_gmt":"2021-02-18T22:30:19","slug":"configuration-as-code","status":"publish","type":"post","link":"https:\/\/blogs.mathworks.com\/developer\/2021\/02\/18\/configuration-as-code\/","title":{"rendered":"An Ode to Configuration as Code"},"content":{"rendered":"\r\n\r\n

\"\" <\/p>

It was a dark and stormy night. The dedicated engineer careened across the rain and mud to deliver her critical package through the challenging terrain of the notorious Pipeline Traverse<\/i><\/b>. She had a delivery of the utmost importance and time was of the essence. However, her confidence was strong. After all, she had delivered similar packages hundreds of times. She quickly but carefully ushered this important delivery, navigating around all of the familiar potholes, hairpin turns, and imposing cliff faces. She was just beginning to really enjoy the thrill of the efficiency and precision of her path when the disaster struck.<\/p>

You see, the familiar path of the Pipeline Traverse<\/i><\/b> changed! It was no longer the same route that she was expecting, and unfortunately she was never notified of the change. The crash was big. And costly. But worst of all, she now found herself lost in the middle of an unfamiliar path with no idea how she could make her delivery. She was lost, and the package could not be delivered as needed.<\/p>

Let me reign myself in before I get too engrossed in this story and quit my day job to pursue cheeseball novels. Cheese aside, isn't our protagonist in this story relatable to anyone involved in managing a software delivery pipeline? It seems just when we are most confident in our delivery pipeline that disaster strikes (usually at 4:30 on a Friday afternoon amirite<\/i> ?).<\/p>

And if the problem is in your pipeline or your pipeline configuration, when it strikes it can be really challenging to debug. This is especially true if your CI\/CD pipeline is buried in the UI. Have you ever found yourself muttering things like:<\/p>

\"Where did I set this pipeline up?\"<\/i><\/p>

\"Who changed my pipeline?!\"<\/i><\/p>

\"I wish I didn't need this boiler plate for all my projects!\"<\/i><\/p>

...or, if you ever have the unpleasant experience of data loss or corruption of your CI config data...<\/p>

\"How in the world did I set that up again (over the course of 3 years and multiple changes)?\"<\/i><\/p>

Well these sentiments are what invariably lead to a better way. Sooner or later most projects address the problem of pipeline management through the principle of Configuration as Code<\/i>. This is one of the many blog topics I have promised you we would address and discuss here, and so finally here we are.<\/p>

Configuration as Code follows the principle that we minimize CI configuration in a CI server UI. What we do in the pipeline should not be defined as obscure and opaque metadata that is held onto by a CI server instance somewhere (where? who knows!). We should instead define that process and pipeline with the code - where the changes happen. Where the changes are recorded, can be reverted, and are completely independent of a particular CI server instance and it's state.<\/p>

With our protagonist delivering along the Pipeline Traverse<\/i><\/b>, while she may not have been able to avoid all crashes, when a problem does show up it is much easier to diagnose and pinpoint the cause and ultimately the way out of the canyon.<\/p>

Our Jenkins plugin<\/a> supports this. Also most other platforms we support, like CircleCI<\/a>, Travis CI<\/a>, Azure DevOps<\/a>, and GitHub Actions<\/a> follow this principle as well.<\/p>

To see this work for our Jenkins plugin, let me show you how you can translate the project we discussed here<\/a> over to a Jenkinsfile using the plugin's support for a feature called Jenkins Pipelines. This project includes a MEX compile step and a subsequent step to run the tests and produce test result and coverage artifacts.<\/p>

It's actually quite easy. This project had the following steps in its pipeline:<\/p>

  1. Tell Jenkins where MATLAB is (there's actually more news<\/a> which makes this easier to manage as well, but maybe that's a future blog post)<\/li>
  2. Compile the mex files<\/li>
  3. Run the tests<\/li>
  4. Process the test result and coverage artifacts<\/li><\/ol><\/div>

    Now instead of defining these in the UI, we are going to create a Jenkinsfile<\/tt> that contains these steps of the pipeline, and this we can check into our project right alongside our code.<\/p>

    Let's start with a basic pipeline that specifies it can use any available Jenkins agent and has a placeholder to add our stages to the pipeline.<\/p>

    pipeline {<\/span>\r\n    agent any<\/span>\r\n    stages {<\/span>\r\n    }\r\n}\r\n<\/pre>
    Step 1<\/b><\/p>
    Remember our pipeline had 4 steps, so let's start with step 1. We need to tell Jenkins where MATLAB is. Actually this is really just done by setting the environment such that the machine itself knows where MATLAB is on the system PATH<\/tt>. When invoking MATLAB the plugin will simply call MATLAB from the shell, so enabling this to work correctly simply means prepending the PATH<\/tt> environment variable with MATLAB for the duration of this pipeline so that invoking matlab<\/tt> from the shell will invoke the desired MATLAB set up on the build agent. This looks like so:<\/p>
    environment {<\/span>\r\n    PATH = \"\/Applications\/MATLAB_R2020b.app\/bin:${PATH}\"<\/span>\r\n}\r\n<\/pre>
    Step 2<\/b><\/p>
    The next step is to build the mex files. As a reminder the example project we are working with here, libDirectional<\/a>, has a nice function called compileAll<\/tt> that does the trick for us. Remember, we showed here<\/a> that putting this in the form of a MATLAB project helps get our environment setup correctly. So our command is just a quick opening of the project and a call to the nifty compileAll<\/tt> function. Here we use the runMATLABCommand<\/tt> step that comes as part of the plugin. We don't need to worry about how MATLAB launches (which varies with different releases), we just worry about the command we need to invoke. It's as easy as adding a stage with this step inside of it:<\/p>
    stage('Compile MEX files'<\/span>) {\r\n    steps {<\/span>\r\n        runMATLABCommand 'openProject(pwd); compileAll'<\/span>\r\n    }\r\n}\r\n<\/pre>
    Step 3<\/b><\/p>
    Now let's run the tests! Last time we touched on this we ran all the tests defined in the project and we generated test results in the TAP format and code coverage in the Cobertura format. I am going to make a slight tweak here, because the TAPPlugin, which processes these TAP results, doesn't support Jenkins pipelines as well as the JUnit plugin. As you might be starting to see, this can be done with some straightforward pipeline syntax that matches the same kind of thing we can do through the UI.<\/p>
    stage('Run MATLAB tests'<\/span>) {\r\n    steps {<\/span>\r\n        runMATLABTests(\r\n            testResultsJUnit: 'matlabTestArtifacts\/junittestreport.xml'<\/span>,\r\n            codeCoverageCobertura: 'matlabTestArtifacts\/cobertura.xml'<\/span>\r\n        )\r\n    }\r\n}\r\n<\/pre>
    Step 4<\/b><\/p>
    stage('Run MATLAB tests'<\/span>) {\r\n    steps {<\/span>\r\n        runMATLABTests(\r\n            testResultsJUnit: 'matlabTestArtifacts\/junittestreport.xml'<\/span>,\r\n            codeCoverageCobertura: 'matlabTestArtifacts\/cobertura.xml'<\/span>\r\n        )\r\n        junit 'matlabTestArtifacts\/junittestreport.xml'<\/span>\r\n        publishCoverage adapters:<\/span> [coberturaAdapter('matlabTestArtifacts\/cobertura.xml')]<\/span>\r\n    }\r\n}\r\n<\/pre>
    That's it, that's all we need. Here is the whole Jenkinsfile for reference:<\/p>
    pipeline {<\/span>\r\n    agent any<\/span>\r\n    environment {<\/span>\r\n        PATH = \"\/Applications\/MATLAB_R2020b.app\/bin:${PATH}\"<\/span>\r\n    }\r\n    stages {<\/span>\r\n        stage('Compile MEX files'<\/span>) {\r\n            steps {<\/span>\r\n                runMATLABCommand 'openProject(pwd); compileAll'<\/span>\r\n            }\r\n        }\r\n        stage('Run MATLAB tests'<\/span>) {\r\n            steps {<\/span>\r\n                runMATLABTests(\r\n                    testResultsJUnit: 'matlabTestArtifacts\/junittestreport.xml'<\/span>,\r\n                    codeCoverageCobertura: 'matlabTestArtifacts\/cobertura.xml'<\/span>\r\n                    )\r\n                junit 'matlabTestArtifacts\/junittestreport.xml'<\/span>\r\n                publishCoverage adapters:<\/span> [coberturaAdapter('matlabTestArtifacts\/cobertura.xml')]<\/span>\r\n            }\r\n        }\r\n    }\r\n}\r\n<\/pre>
    Now just check something like that into the root of your repository, and you will be good to go. Here's how you create a Jenkins job that uses it:<\/p>
    \"\" <\/p>
    ...and now you can see the pipeline runs just fine and dandy as it pulls its pipeline instructions from the Jenkinsfile instead of the Jenkins UI:<\/p>
    \"\" <\/p>
    ...and now since this pipeline configuration is checked in, it travels with the code, it can be reverted with the code, it can be reviewed with the code, and it can be reasoned with the code. Code is beautiful, especially when backed by a little bit of source control, MATLAB projects, and what we hope are useful CI platform integrations.<\/p>
    Now let's all burst out in song!!<\/p>
    ...and finally, now that we have built our project, tested it and generated some test results and coverage artifacts, we can now process those artifacts using other plugins meant for that purpose (the JUnit plugin<\/a> and the Code Coverage API plugin<\/a>). I'll just add them to the same stage as the test run.<\/p>