Nejc Zupan - Learn How We Deliver. Continuously.

Discussions in the hallway are the best part of this conference. You don't have slides there, so I won't use them here either. I do have them by the way.

Have you deployed anything to production this month? Week? Today? If code only sits on your local computer, it does not give value to your customer.

What would deploying look like if it was easy? You fix a big, push the change, the tests are run, they pass, production gets updated automatically or maybe after one push of the button. Instead of saying 'the fix has been committed and will be in the next release', you want to say 'it is fixed'.

The bigger the change, the harder it is to deploy. One fix, with one data migration, is fast to deploy, and easy to undo if needed. With three fixes: it gets harder. For one fix, do you really need a developer, a QA person, a project manager, a sysadmin?

When you push to a git repository, you can hook up actions to start testing and deploying.

Tools are interchangeable. You are smart people, you can figure out how to do this. More important is why you should do this.

When a pull request is made, we copy production data to staging. This may be a lot of data, so in case of SQL database we only copy a subset. The pull request is deployed to staging, so a reviewer can immediately check it there. We have 100 percent test coverage. We have regression tests. For new employees, I want them to deploy something to production the first day, going through the whole process. This is very empowering. It keeps developers happy.

Code ownership. If you know that your pull request may be deployed within the next twenty minutes, then you will be careful about what you put in the pull request.

Tip: if you don't have this yet, then start doing this with a very small project.

Give your customers access to the staging machine that has this change, so they can check it.

We host everything on Heroku. For the highest paying levels, you have a button to revert the code change and the database change. Heroku does this well. If you are not in the business of hosting, then don't do hosting.

We have about ten people in the company. We do have a few small Plone Sites.

For us, the only way to get code into the master branch, is via pull requests.

We spend more money on the staging servers than on production.

You can automate stuff like: if a new tag of a package is generated, push it to your internal PyPI.

What about big features instead of bug fixes? You can use feature flagging, showing for example a new UI to only a few people. But anyway, it is rolled out to staging, you test it, if it works you can deploy it. For big features it can take longer to get everything correct, so you just don't merge the pull request yet.

I will never write code without writing a test. For an emergency fix, it is still better to spend twenty minutes to write a test, instead of spending two hours later reverting and debugging.