Building an efficient development process with Github and Chloe 1.0
As head of development for an new and exicting product, an efficient development process is essential to it’s success. The first aspect was to implement the usual applications for an robust agile environment; including JIRA, Slack, CircleCi and GitHub.
Following the usual rules of GitFlow, each developer would create a new feature branch, code the relevant features and produce a final pull request for code-review. At the point of raising a pull request the usual CircleCi test would be run and the code run through various unit and functional tests.
But for the busy development environment I found a number of areas which needed more efficiency.
Reducing common development mistakes, which took me onto developing `Chloe 1.0` over a glass of wine during the evenings.
Have you bumped the VERSION?
We use Semantic Versioning 2.0.0 throughout all our development projects. It should be common practice to bump the version number on any update to the source code! With time pressures and a fast tracked project, this is sometimes missed during the generation of a pull request. With a multitude of repos using different languages including C++, NodeJS and Typescript, the version files are some what different.
For our C++ projects we use the usual VERSION file, any configuration packages use a VERSION.cfg. For the Node and Typescript projects the standard package.json file.
With the `versioning status check` the relevant version file is automatically checked during the pull request. Firstly to make sure its a valid semver version, secondly that the version is higher than the base branch. This gives us good branch protection and with multiple pull requests, gives reliability that each feature is generated with the correct version number as this may have become stale from previously approved PRs.
Have you updated the CHANGELOG?
All code requests and bug fixes are generated as agile stories in JIRA, however we maintain a repo CHANGELOG.md. This allows the development team to easily check on updates to a any given repo. Again this seems to be an element that doesn’t get updated on each PR. Were all culprits to this.
With the `changelog status check`, the change log is checked to make sure it has been modified in the pull request and that it includes the version number relevant to the PR. This can be the usual repo CHANGELOG.md, or any other file containing change log information.
Does the README.md reflect the latest changes?
The README file quickly becomes stale. New dependancies get added, pre-requisite libraries need installing and those usual `did you run…` comments. This usually comes to light when a new developer joins the team and is unable to get the project up and running.
The `file changed status check`, allows us to check if a specific file or files have been modified in the pull request compared to the base branch. With all the status checks this can simply be a warning as the files may not require any modification.
Do we have an Agile Story?
All development should have an agile story attached. We use JIRA which is a fantastic agile management tool. All development requirements are captured and wrapped up into numerous sprints. The agile story will detail the requirements and updated with the relevant fixes and resolutions before they are marked as done.
Using a `jira status check` the pull request or commits must contain a valid JIRA story, bug or task reference in the commit message. This then allows us to track back on any historic commits in each repo. For multiple JIRA references we append a semicolon, thus `JIRA-123;JIRA-456 Fixes for packages management`
The above may all seem like common sense for any development team. But in the real world it gives the product manager the ability to make sure all of the key tasks have been completed prior to conducting code reviews and approving development work.
I would return from development meeting only to go into Github and find 25+ pull requests waiting my review. Only to find most of those checks had not been completed, bouncing each one back to the developer to re-submit the pull request.
So I thought there must be something out there to streamline these processes. I found a few solutions but they didn’t give the levels of control we required.
Sitting at home with a cold glass of wine I fired up my laptop and started to write a solution to provide all of these required status checks and version control. `Chloe 1.0` was born. I can now configure all of the required status check for each organisation repo and be safe in the knowledge that each pull request that arrives has met all of the key requirements.
‘I’m using this for my own selfishness'
I feel that many development teams and product managers will benefit from using this solution for an efficient development process. If I get enough people interested then I’ll get it hosted. It would be great to see other individuals and companies using this solution.Please let me know your feedback and shout if you want access to `Chloe 1.0`. You can aslo find me on twitter Paul David Ashford.
Look out for my next article and how to handle automated hierarchical builds.