I have this idea for a “pull request watcher”. It is a tool that will help you when your are working in a team, that works on different features.
It is pretty normal in a tech company to have developers and product managers, where developers task is to make features and product managers task is to ensure that they get made correctly according to the company’s demands.
A developer can typical finish multiple tasks during a day, which means that the product manager has to look and test multiple tasks, along their meetings, but that makes a difficult problem; how does the developer show the product manager the different tasks that he/she has finished? With github it’s very easy to create a “pull request”, which is a way to “propose” some changes to be merged into the application. A awesome way to work, since you can work on something and it will actually only show up live when it has been agreed upon and “merged”, which means combine into the app. However most product managers does not read and understand code, that can be complicated and long, and only really has to know if a button does what it is suppose to do.
The developer can now setup a new testing environment only for that feature/pull request, so that the product manager can look at it, but with many tasks done during the day, that can be a big hassle and time consumer.
The solution that nearly all people use now is that when the developers internally has agreed on merging it is done and then product managers can test it later.. but as soon it is merged other developers will start building on top of the changes and if the features was not made correct according to the product managers, a long unproductive task can start refixing that task again, that essentially was already agreed upon when merged, and thereby degrading the quality of using pull requests. That is sad, because pull requests is awesome!
The quick but not quite there solution
A lot of developers have already felt the pain of this problem and therefore built and used existing services like (codeship and circleci) to test new pull requests before they get merged. The problem is that they are all focused on code and not on the actual service that is made, but that is because it is hard to solve!
And how takes care of all the managing, updating and closing those test environments that has been created for all those different features?
It is also hard because a application often has a lot of dependencies, it needs a database, web server, queue-systems, background workers and all that can easily take up multiple machines until quite recently.
Docker Compose (or just recently fig.sh)
With containers a lot of things has become a lot easier and tools has built on top of docker to make projects easier to get up and running. Docker Compose is a tool that after you have defined what you need (web servers, databases), runs and orchestrates all of them for you, just by a single command and an expressive declaration.
So this “solves” our previous problem, then we just need something that takes cares of all this, we wanted to make is easier to make features, not more difficult!
The Pull Request Watcher
What the pull request watcher will do is, whenever a pull request is created, it copies the code and runs docker compose, which will bring up all the necessary components and post a url make you access that specific feature. Whenever the pull request is updated with new code (commits), the pull request watcher will take down the previously docker compose environment and spin up a new one with a new url ready for the product manager to look at and test. Ending when the pull request has been merged, the pull request watcher will ensure that the test enviroment is closed down to save resources, all this done without putting more work on anybody and actually saving the developer and product manager time.
No more time wasted asking: “where can this feature be test?”, “is this done yet?”!
No more time wasted setting up, configuring and telling product managers where the feature can be tested!
No more code being deployed that has not been tested because there was not time enought to test i thoroughly.
All this by a tool called “pull request watcher”!
(Note to myself after writing this down: I have to built it! I need it!)