Why I will not use Github Actions in future
Github Actions, as a concept, is very powerful. Tight integration with Github gives it an edge over any other continuous integration & delivery tools. However atleast for me, it is a pain to live with.
Half done features
There are many conceptual features which say rapid development from the Github side, like reusable actions, workflows, secret management etc., Most of them had lot of gaps in addressing real needs. However, I was patient believing it would be fixed in upcoming months.
Layoffs at Github
The initial rapid phase of evolution of the Github Actions was lacking in past year. Functionalities that were half done doesn’t evolve in a rapid phase.
Reusable workflows
Reusable workflow are great feature. Again it’s not complete. It will provide a good way to start with our needs. After initial development, the reusable workflows reduces readability of what’s going on because we should switch between repositories. Complex upstream/downstream kind of pipelines cannot be done.
Upstream and downstream pipelines
Github action as of now, is done from a repository stand point rather than a product build & packaging stand point. Let’s say we have multiple microservices and we like to manage the continuous integration and continuous delivery of a cloud native product.
We will spend more time on Github action in re-thinking what we actually want & what can be done with Github Actions. Comparitively Jenkins kind of tools are done as a full fledged continuous integration & delivery perspective.
Community
One good thing about Github actions is the community. In short span of time, amount of shared github actions has grown exponentially. However, we cannot compare the community ecosystem of long time alternative like Jenkins.
Complicated security features
Github action keeps adding more security features. These are done to follow a global practice that suites for everyone. Many of them over complicate the build process. While working on a release or a tight deadline, getting blocked by a security issue to rethink code access control, secret sharing, etc is a big pain.
Comparitively, a self hosted continous integration where it is fully isolated from external world that has the security practices that matches our teams needs, member’s expertise and seemless integration with enterprise tools like Vault makes it more productive. A security expert can review, fine tune the whole continous integration tool without individual developers focusing on resolving this issue. Once fixed and ironed out, the number of times to revisit this area would be minimal, because the software is stable and mature.
Alternatives
The classic — https://www.jenkins.io/
- Huge community. I have faced many complex problems while building Jenkins pipelines. But always there is some one else who faced similar issue and there is a solution for it. Jenkins docs, stackOverflow, Github issues etc would have multiple people discussing
- long term expertise in solving continuous integration problems
- Wide array of extensions & plugins
The modern — gitness
- Gitness is an Open Source developer platform with Source Control management, Continuous Integration and Continuous Delivery.
- https://gitness.com/ — for more details
Other alternative — Drone
- Drone is a Container-Native, Continuous Delivery Platform
- However, at this moment, I would go with gitness compared to Drone, as it has more holistic code management vision.
