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 :
- Cloud : Code and deliver assets/artefacts or Docker images on Github.com
- 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 }}
β¦βοΈ 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.
Top comments (0)