I’m frequently asked by customers if they can store OutSystems applications and modules in their version control systems, and GitHub is the platform that tends to be mentioned the most. One of the primary reasons I hear is that SysOps teams look into GitHub before deploying new application versions to Pre-production or Production. For many organizations, GitHub is considered the “source of truth”. Every change is documented there, and each change is linked to user stories. 

Since OutSystems is highly extensible, I decided to see what it would take to provide visibility into the history of OutSystems application deployments in GitHub.

I know that the OutSystems CI/CD pipeline produces a manifest file containing a list of the application versions that were deployed. The file also includes comments added by developers documenting what has changed in each application version.

So, a nice starting point would be storing deployment manifests in GitHub, and allowing customers to compare changes between versions.

Steps to add a change manifest to GitHub

First I followed the steps described in “How to build an OutSystems continuous delivery pipeline” and set up a Jenkins pipeline with 3 environments: Development, Test, and Production.

I added an additional step after running tests: “upload to GitHub” and removed the steps related to environments I don’t have. When the pipeline reaches that step, it uploads the manifest file in the configured Git repo.

Here is my JenkinsFile and what my pipeline looks like.

image-1-bp-outsystems-deployments-with-github

Here is the Python script the pipeline calls in the “Upload to GitHub” step.

I installed and configured the GitHub Connector, available in the OutSystems Forge so that manifest files are uploaded to GitHub.

So the deployment flow is now as follows:

  1. The developer tags an application when it is ready to move forward in the pipeline
    image-2-bp-outsystems-deployments-with-github
  2. The TriggerPipeline LifeTime Plugin periodically scans for newly tagged application versions
    1. If one is found, the Jenkins pipeline is triggered

      image-3-bp-outsystems-deployments-with-github
  3. Applications and their tests are deployed to my test environment

    image-4-bp-outsystems-deployments-with-github
  4. The tests are executed (and they pass)
    image-5-bp-outsystems-deployments-with-github
  5. The deployment manifest is then uploaded into GitHub
  6. The full execution log is available in Jenkins. Here is an example
  7. The SysOps guy goes into GitHub repo and sees this:
    image-6-bp-outsystems-deployments-with-github
    image-7-bp-outsystems-deployments-with-github

Voilá!

Final thoughts

Thanks to the extensibility of OutSystems and an existing connector, it was straightforward and quick to extend the OutSystems pipeline. It just required a little Python code and some simple configuration.

I used GitHub because it comes up frequently, but any other version control system could have been used.

This experiment gave me a lot of new ideas to explore, like:

  • Uploading OutSystems application packages so that code is stored in an external repository
  • Integrating GitHub with JIRA so that changes are connected to user stories
  • A button to deploy changes to the next environment… and if we can deploy changes to the next environment, what about deploying a previous version into an environment?

There are really no limits to what you can do with OutSystems, and many opportunities to make the lives of the SysOps teams better. I’m sure you would agree this is a very worthy cause.