During development, there are many occasions where we have to do things that are not directly related to the feature we are working on, or things that are repetitive and recurring.
In the time span of a feature development, this can often take as much time to do as the actual development.
For instance, updating your local dev micro-services environment before testing your code. This task on its own, which usually includes updating your local repo version, building and starting several services and many times debugging and fixing issues caused by others, can take hours, many times just to test a simple procedure.
We are developers, we spend every day automating and improving other people’s workflows, yet we often spend so many hours doing the same time consuming tasks over and over again.
So why not build the tools we need to automate our own workflows?
In our team we decided to build a few tools to help out with some extra irritating tasks we were constantly complaining about to each other.
First one was simple, creating a slush sub-generator. For those of you who don’t know, slush is a scaffolding tool, like yeoman but for gulp. We used this to create our Angular components.
Each time we needed to make a new component we had to create a new folder, with three files:
Comp.component.ts Comp.jade Comp.less
Each file, of course, has its own internal structure of predisposed code, and each component had to be registered in the app module and the main less file.
This was obviously extremely annoying to redo each time, so we automated it. Now each time you run “ob-genie” from the terminal, you are asked the name of your component and what module to register it with, and the rest happens on its own. We did this for services and directives too.
Other than saving a lot of time and frustration, this had an interesting side effect – people on the team were creating more components than before! This was good because it resulted in better separation of code and better readability. Seems that many tim the developers were simply too lazy to create a new component and just chucked it all in together. Btw, Angular-CLI has added a similar capability, guess great minds think alike.
Another case we took on in our team was to rid ourselves of the painstaking task of setting up the local environment. This I must say was a real pain point. Updating the repo, building and running the services we needed each time could take hours, assuming everything went well.
There have been times where I spent days on this just to test the simplest of procedures.
Often I admit, I simply pushed my code to a test environment and debugged it there.
So we decided to build a proxy server to channel all local requests to the test environment.
For this we used node-proxy, a very easy to configure proxy. However, this was still not an easy task since each company has very specific configurations issues we had to work with.
One thing that was missing was proper routing capabilities. Since you want some requests to go local and some remote we added this before each request.
[javascript][gist id=db0ea3c7989469a0b74f06180a3512ea file=start-proxy.js][/javascript]
We passed as an option the routing table with a regex for each path, making it easy to configure which requests to proxy out, and which in.
[javascript][gist id=97046943d7f2b3d320c7d9145bb2f776 file=routing-table.js][/javascript]
Another hurdle was working with HTTPS, since our remote environments work on HTTPS.
In order to adhere to this, we needed to create SSL certificate for our proxy and the requestCert parameter in our proxy server to false, so that it doesn’t get validated.
The end configuration should look something like this.
[javascript][gist id=d1046ef591c0a1c88f02464f0ce7c586 file=config.js][/javascript]
With this, you should be able to run locally and route all needed calls to the test environment when working on localhost:2109.
So to conclude, be lazy, make your work easier, and use the skills you have to automate your workflows as much as possible.