You Don‘t Need, Continuous Integration or Continuous Deployment for your Startup
Imagine you‘re writing your new startup, it‘s going well. You‘ve built your API, maybe you have a front-end, maybe you don‘t. But you know for sure that you‘re ready to start testing it. Since it‘s 2022, you will almost definitely be deploying to the cloud. This is where the single biggest mistake in your startup journey can happen. "Oooh! Look at this cool CI/CD tool! I should use this on my startup!"
Now, I have nothing really against CI/CD tools themselves. Rather the problem resides with the fact that small teams of 1 to 10 people think they absolutely need them. Sure it is really cool to have your prod code mirror your git, or have multiple branches and build pipelines, but when it comes to DevOps and Architecture, Mark Richards & Neal Ford say it best in there book Fundamentals of Software Architecture: "There are always trade-offs." The biggest trade-off I see teams omitting to confront is the fact that using CI/CD will inevitably pull you from actually developing your application. At my current job (enterprise software), we have one developer who is entirely committed to maintaining CI/CD tools, in our case Jenkins, Nexus, and EC2. This is not a big trade-off for us, since the company is fairly large, but imagine if we weren‘t. Taking a developer off of active development in a startup to work on tooling like CI/CD can kill development and sprint goals, this results in lower growth, less investment potential, and the death of the company. Most people (and for some reason most startups) neglect the fact that things need to be maintained.
What Should I do?
How about we look at the other end of the spectrum? This less mechanized sort of deploy process would involve a Senior Developer, Project Lead, or other high ranking member of the organization directly deploying the application with a script, or some other more primitive deployment technique. This approach is highly sustainable for small teams, but lacks the security for massive organizations. This approach is really effective, and if the project you‘re working on is relatively small it should cover all of your bases. Before you mention that you ship new features every 3 hours, just remember, finished features don‘t have to be pushed to prod the minute they‘re done, instead, you can use nightly builds with simple scripts. Your Linux server hosting your site has a thing called a "crontab", feel free to write a simple bash deployment script, and call it a day.
CI/CD tools can be fun to use, and fun to setup. But you do not need them. Realistically, your product (unless it‘s being used by thousands of people concurrently) will never need continuous deployments, manual, or script driven deploys will simply cover all of the bases. Now let‘s get back to developing! The investors are waiting!