Speeding Up Time to Market with Custom Ansible GitHub Actions

Intro

Recently, we started to migrate our onPremise Jenkins/Gitlab based Continuous Integration platform to Github.com.

After having migrated our code and build tool from gradle to maven, implemented all the classic CI, including Continuous Delivery,

we wanted to go one step further : achieve Continuous Deployment.

This post is about how we achieved that, while relying on hybrid onPremise and Cloud services, and the software we developed to achieve that, with an industrial approach.

📘 Our mantra : getting platform oriented

Our core mantra that would drive all of our DevOPS decisions was to

perform a weak couplage... and avoid self hosted runners.

OPS would deliver us a ready to use platform (servers and deployment pipeline) while programmers (Dev and Ops) should integrate the OPS pipeline to implement the Continuous Deployment Pipeline.

⚡ The pipeline

Finally, we should get a whole pipeline as follows :

1. Cloud : Code and deliver assets/artefacts or Docker images on Github.com
2. onPremise: Delegate deploy tasks by calling dedicated & ready-to-use Ansible Tower Job

Below see the same version deployed to both environments :

On each deployment you can see the reference to the GH Action :

🚀 Deployment cases

We finally achieved the following deployment pipeline :

• When a PR is merged into the develop branch : trigger a deployment on integration environment
• When a released is triggered : a deployment in Qualification is triggered, but waiting for a reviewer to accept it
• For production environment : same approach as previous item, eventually with different reviewers

📦 Package and deliver the Tower Action

To deliver the deployment, we naturally have chosen to implement a dedicated Github Action so other developers could use it too to implement deployment workflows.

Finally we managed to release this as a public action on Github Action Marketplace :

👉 Notice that we did put a lot of care to be able to produce public code, be able to manage secrets and not being too specific to our needs. This is an important part of our philosophy.

You can get a closer look as the action sourcecode below :

opt-nc / tower-deploy-action

Github action pour le deploiement d'application via Tower

tower-deploy-action

This Github action aims to interact with Tower servers.

It connects to a Tower server and launches a job based on a template id, if needed an extra_vars file can be send.

Usage

See action.yml

If you need extra_vars data, you have to first checkout the repository you aim to deploy and that contains the extra_vars yaml file template The templated yaml file have to be put in the src/main/resource folder Default filename is tower_extra_vars_template.yml, if you want to use another filename, please use extravars_template_filename input.

Deploy an application from main branch

  integration-deploy
    name: Call deploy action
    runs-on: ubuntu-latest
    environment: integration
    steps:
      - name: Checkout my repo
        uses: actions/checkout@v2
      - name: Invoke deploy action
        uses: opt-nc/tower-deploy-action@v1.3.2
        with:
          vars: ${{ tojson(secrets) }}
          asset_url:  https://github.com/my_org/my_repo/releases/download/integration/my_app.jar
          tower_template_id : 45
          tower_url: ${{ secrets.TOWER_URL }}
          tower_password: ${{ secrets.TOWER_PASSWORD }}

…

View on GitHub

⚙️ Maintaining the pipeline

As any kind of dependency, a Github Action needs to be maintained, and as an end user, you need to monitor that (I mean... you really have to).

Fortunately, since 2022/01/31 this can now be achieved through the standard dependency graph (the same way you monitor through any package managers like npm, NuGet, Maven, or RubyGems).

From any repository which uses Actions, you can now see your Actions workflows listed alongside any other dependencies in the Insights/Dependency Graph experience:

The dependency graph is the foundation of GitHub’s supply chain security capabilities because understanding what you depend on is a crucial first step toward securing software.

We can configure Dependabot version updates to keep your Actions dependencies up to date automatically... I mean as part of your development workflow through automated Pull requests.

See official Github Blog Post about this topic.

Benefits

During this first Github Action development we had the following benefits :

• Even better code-related collaboration with OPS Teams for code around Tower calls and security concerns
• Better questions and responsibility around deployment and the deployment reviews and roles
• Generate DevOps metrics to get data driven around on this area
• Optimize workflow to save money (switch from Docker image to js under investigation) : the faster your pipeline runs, the less money you spend
• This discipline behind the mantra opens the door for a very wide range of deployments, making us very productive at no additional development cost
• As on Github.com CPU time and storage come at a cost, cost and performance do now are investigated since the very beginning and are data-driven : we have started to shift left on these aspects too

Resources

• Keeping an eye on GH public roadmap for more information about upcoming supply chain improvements in this area.

🎦 Intro to Gh Actions

🙏 Acknowledgements

I really want to thank all the people that made this first success possible : Dev, OPS, financial services, RSSI and CIO for their confidence. Without all this engagement this pipeline would have never been come true.