Continuous Deployment & Continuous Integration — 10 things to do and not to do!

If you are just getting started with continuous deployment, here is some tips and tricks that you should do and not do.

Do use an external service

If you are just getting started, running your own CI/CD solution is not the right place to spend time. When you are first getting started there are so many things that can go wrong and you don’t want to debug the centerpiece of your setup.

Don’t commit passwords

You should never commit password into your version control system simply because they don’t belong there. I have done it myself but it is a bad habit because:

• The password will always be part of the VCS history
• Developers should not have access to production credentials
  - If you don’t have access, the attack surface is simply smaller
• It is much easier to get hacked because every developer has every credential
• If you change the password, you have to commit it again

Do start slow

I have seen too many times that companies want to get started with CI/CD and the go all in and end up with a system they don’t really understand. New solutions introduce new kinds of problems, so don’t reinvent everything but do it in small steps where you always can go back if something goes wrong!

Don’t deploy with git

I wrote a whole article why you should not deploy with git, you can read it here:

https://medium.com/@kevinsimper/why-you-should-not-use-git-for-deployment-e0590bcb185c

Do build docker images

You should use a continuous integration service like CircleCI to build a docker images of your app and then run your tests against that image. If tests are successful you should push that specific image, not let another service build it again. The easiest reason is because it would be a waste of time building it twice, but also because if you don’t push that specific image, you are not sure if tested with the specific dependencies. Something on npm or apt-get could be upgraded from the time your test ran and when you are running apt-get or npm install again.

Don’t manually run bash commands

Manually running bash commands to deploy is a recipe for disaster. You will certainly at one point forget a command or do it in the wrong order. What you should do is an A/B deployment, where you spin something up alongside the current live version and then if the B version works, promote that and remove the A version.

Do put all assets into the container

You should install and compile every asset inside the container, this makes it super easy first of all to pull down that specific container if there is an error and debug that, but also easy to move around as you don’t have to remember to do anything more with the container other than simply starting it.

Don’t mount volumes in production

From the former point of putting all your assets inside the container, you should not mount volumes in production at first. The image should be able to start without any new files, if you can do that, that makes it really easy to deploy to production as you don’t have to do any steps before starting it, eg. git clones.

Do tag your images with a version

If you are just pushing “:latest” right now on your continuous integration service you are screwed if you want to do a quick rollback as you don’t have the previous as it was deleted when you pulled down the latest. You should either tag the image with a continuous number, as that is easy to remember and reason about (it continues to be bigger) or use the git hash, but that has the downside of you have to look up the git hash to match.

Don’t forget to cleanup old versions

If you don’t look out you will quickly fill out your disk and you will facepalm why you did not think about that ;)

Was there something I forgot or something you think should be added? I would love to know in the comments below! I respond to everybody! ❤