Avatar of Akshay Srivastava
Needs advice

Hi there,

I'm looking to build up my own Auto Deployment tool for internal purposes (example deployhq.com, deploybot.com). I'm confused as to what tech stack I should use for the entire platform. My primary concerns are running parallel and concurrent builds to different targets (servers).

I have been researching and thinking of using Rails as backend and React as front-end (both deployhq.com and deploybot.com are built on these stacks).

Please advise.

6 upvotes·13.2K views
Replies (3)

Hi Akshay,

If the goal is to have a system that is purely to be used within your company, then it would be a good idea to have something scrappy. However, lot more has to be considered if you are planning to offer it as a SaaS or PaaS.

In either situations, the first factor I would consider is Return of Investment. You can build a really fabulous system, but if it is only going to help you little bit in the overall scheme of things, it may not be worth the effort. In other words, you can build - job management, scheduling, progress tracking, auto recovery, maintaining container state etc all by yourselves, but it may be worthwhile not reinventing the wheel when these solutions are already available (Jenkins or Team City for example).

If I were you, I will offload majority of the features like triggering jobs (build jobs), monitoring progress, errors etc to Jenkins. Every deployable unit can be dockerized, so that you get an uniform interface to validate whether the service is up and running.

You can build a thin vanilla UI on top of Jenkins' apis using React, or simply jQuery or Svelte. My personal preference would be Svelte.

If Jenkins is not a viable option, Go is the perfect backend for anything related to devops. You can use any Golang frameworks (Gin or Beego for instance) and have a front end in React / jQuery / Svelte. Hope this helps.

4 upvotes·6.9K views

I guess the bigger question is why are you building your own auto deployment tool for internal use? Assuming that is a good idea, I think this depends on how quickly you can develop what you need in a language and framework that you are comfortable with, choose that over everything at this stage. You could build what you need using rails easily and anything that needs to run as a backend process for builds etc can be farmed out as a job somewhere and can be as simple of complex as you like. You can even have those jobs spooling up docker tasks with an entire rails stack in to to do what you need. In summary, have your front end create jobs with enough data in to go build stuff, then queue up those builds with something job like. The jobs can be simple rake tasks or entire docker containers doing anything you like. Perhaps take a look at rails, shoryuken for queueing on AWS, AWS Elastic Container service for actually doing the jobs.

3 upvotes·6.8K views
View all (3)