We previously mentioned that Team Inception was focusing on making the deployment of packaged code a better situation for those in Red Hat IT. Here is a high-level overview of the work that we are doing:
What is our Release Engine?
The release engine will provide the functionality necessary to continuously deploy packaged code from the development team's continuous integration server of choice to all environments and automate certain business processes associated with the release of code. The engine will specifically focus on making releases user-friendly, repeatable, auditable and agile. The key to the release engine's success is straight-forward; it needs to be light-weight, fit to purpose and easy to extend and modify by development and operations team members.
How are we limiting initial scope?
We will be automating the RPM deployment of code to our QA environment for a targeted team for 2 high-profile projects. This scope will allow us to release a minimal viable product (MVP) in approximately 5 two-week sprints; although we can begin alpha testing with sprint 4.
Minimal Viable Product Features:
- Ability to use customizable release playbooks allowing users to define the individual steps that need to be taken for their specific release (FWIW: this will hopefully transform a manual documentation process which is taking at our best guess an average of 2 days x 2 people to complete for a medium-complexity release).
- Ability to execute commands on secure systems
- Ability to stop the release upon command failure
- Ability to promote RPMs through environment repositories, interact with Puppet and Taboot (home-grown scripting tool)
- Respect user authentication/authorization. We have a well-developed program for who can perform releases in certain environments. We want our release engine to incorporate those practices.
- Log the release & output the log in an easily readable and accessible format
- Ability to send notifications at particular points in the release process (e.g. IRC notification upon start/finish/rolling nodes, Email list notification)
How far along are we?
- Sprint 1: Basic design documentation, release engine prototype, updating logs & onscreen results **Completed
- Sprint 2: harden prototype code (including auth groundwork, test coverage, etc), notifications emitting to the bus, engine stopping upon command failure **Completed
- Sprint 3: Fully integrate the concept of release playbooks, implement a first worker (RPM promotion to yum repo), complete auth work
- Sprint 4: Continue to add our key workers; notifications, puppet, taboot, etc. I would like to see teams alpha testing at the end of this sprint.
- Sprint 5: Finish key workers and "something" will need to happen with our change records here. Legit: This may be a "what did I forget and/or didn't know about" sprint. If it doesn't get filled with things I don't know about now, I will fill it with targeting our Stage & Prod environments.
I know at least one of you reading this blog wants to know why we chose to build our own tool over using something already out on the market. I know this because 9 out of 10 people asked me that question at Red Hat Summit. Next week, I will try to give some insight into how we arrived at that decision.
Last updated: March 7, 2023