Start with the deploy pipeline

If you’re starting out a new project, don’t start with the Log In page. This is definitely not your core feature and there are a lot of other things to start out with. I know, it’s a cliche, but most developers want to start with the Log In page.

1. Choose a CVS

Whether it is Git, Mercurial or Subversion, choose one. Even if it’s a simple project, you’ll be better off with a Concurrent Versioning System. It allows you to keep a history of changes, to collaborate with others and to easily review your code in online tools such as Bitbucket or Github. These online services also bring you a useful set of management tools such as code review, issue tracking, forks, pull requests, markdown documentation support, deployment support and many other, depending on the platform of choice.

Even if you’re not writing code, you might also use git to keep track of configuration files or anything that you don’t want misplaced or easily deployable to any machine in the world, be it your development box or a server.

2. Choose the Technology Stack

Next, you’ll need to figure out what technologies you’ll use in your new project. This is important because at this point, you might find out that certain frameworks and libraries don’t work well with others.

It also helps to draw out some simple schematics on how you see services merging and working together. “What’s the information flow going to look like? Who’s responsible for what?” These are questions you should be able to answer up front.

During your technology stack research, it might be a good idea to see what are the latest developments for the tools, frameworks and libraries that you’re planning to use. You might find out that completely new versions have been released, that are much faster and simpler than the older ones. The Internet is moving fast and it’s not a bad idea to keep up with the latest developments.

3. Build the Deployment Pipeline

This is something that is easily overlooked and I can’t stress enough the importance of this. Configure a deployment pipeline that deploys your project to an incipient production environment, even if it’s a small and simple machine that you’re already using for something else, or a friend’s server. And do it as soon as possible.

Having a deployment pipeline early on has several advantages, some of them being…

It will prove that the code works in a production environment, that might be on a different platform than the one that you’re using for development. For example, you might be developing on Windows, but your project is destined to work on a Linux server.

It will force you to keep all environment-related configuration options in a non-versioned configuration or environment file. This is pretty important early on, as you don’t want your secret SSH keys into the repository.

You’ll have unit tests running in an isolated environment, which is a big step forward in ensuring that the code you write will actually work.

Choosing a Continuous Integration Service

The real power of Continuous Integration comes when you have unit tests, or any kind of tests, including integration or Browser tests. Having tests for your code means that you can easily refactor, adapt and grow your project without breaking stuff along the way.

These days, users have big expectations from new products, and a crappy service that keeps breaking stuff at every release is not going to take you a long way. As the project grows, the lack of tests will make it become fragile. I know it sounds weird, but when everything is manually tested and you release it into the world, you’ll start to be reluctant when it comes to changing working code, to keep it from breaking, especially if you don’t plan to manually test everything at every release. This will entice you to duplicate code, just to add some new parameter, since altering the original method is out of the question. And you don’t want to break the existing, working code, do you?

If you’re telling yourself that you’ll add tests later, stop lying to yourself. You and I both know that realistically, you won’t. You’ll keep on building and building and building and the unit tests will never come later. Not to mention that it is exponentially harder to add unit tests to a codebase that didn’t start out this way. There are entire books on how to add tests to legacy code, as it’s next to rocket science in terms of complexity.

Unit tests also bring in another healthy benefit: They make you structure your code so that it’s actually testable. Methods and classes will have less dependencies, and become more of a “data in — data out” system, which is actually exactly what you’re aiming for.

These are all benefits of testing your code early on.

But we went too far into the forest. Coming back to the deployment pipeline, and especially if you have tests, you can benefit from a Continuous Integration service such as TravisCI or CircleCI that have the main purpose of quickly spawning a machine, deploying your code and running your tests. The true power comes with the fact that you can easily configure the CI service to only deploy the code in production if the tests pass. This means that you can go ahead and commit or push just about anything, because the code won’t make it to production unless you’ve committed a stable, tested codebase.

Now, isn’t this awesome?

CircleCI has a free plan, for small private projects, so you won’t even have to pay a coffee to benefit from a powerful, production-class CI system. If your project is Open Source, you can use either TravisCI, CircleCI or pretty much any CI system, as most of them handle open-source projects for free, just to get awareness from developers and support the open-source community. After all, we wouldn’t be where we are today if it wasn’t for the Open Source initiative.

Wait, there’s more! There are other services out there such as CodeClimate or CodeCov that integrate with your deployment pipeline and provide you with code coverage reports. Not to mention that you can easily set up rules so that the code doesn’t make it to production if its quality is not up to your standards.

Not only you’ll get quality reports on your new project, but you’ll get to see trends and witness the growth of your project in terms of quality and quantity. Also, if you’re bringing in a colleague or friend to work with you, you can easily make sure that you’re both bringing value to your project, crafting high quality code, and, therefore, happy users.

All being said, even if your product isn’t doing much, simply having a deploy pipeline set up motivates you to get things done faster, because putting anything new in front of your customers or users is just a few clicks away, which is a huge step forward in product shipment than it was 10 or 15 years ago. Just think about it!

Now, I’m curious to know: What project are you starting out and how do these guidelines work for you?