Thread by @PaulDJohnston

THREAD:

So, let's have a quick chat about CI/CD and #serverless.

This will be more "overview" than in depth (it's twitter after all)

CI and CD* are not the same thing

*and there are 2 types of CD

CI is Continous Integration

When multiple developers are working on one project, at some point they have to come together and combine their efforts...

...therefore Integration

And that happens continuously over a project

CI essentially allows for developers to setup shared environment and tests that everyone can agree upon, so that everyone can work within those constraints.

Generally this is integration also runs automated tests to check whether what a developer has added passes those tests

CD is Continuous Delivery or Continuous Deployment

Let's do Delivery first

Basically it's Continuous Integration (CI) + automatic deployment to a staging environment of some sort.

There is then a manual step to deploy into production

And for Continuous Deployment the additional stage over Continuous Delivery is the automation of the deployment to production.

In other words, if you're doing Continuous *Deployment* if you make a change to the codebase it is integrated, tested and if it passes tests, deployed.

So what does this mean for #serverless?

Does anything change for CI/CD and #serverless?

The implications may not be immediately obvious, but they are important.

The biggest implication for #serverless and CI/CD is that in the future, development is primarily going to be done on the cloud, and not on "my machine"

Why?

Because #serverless relies on other services. Constantly mocking/testing these is hard. Easier to simply do it in cloud.

A lot of effort has been made to make development and testing tools that work locally, but I think that is missing the point with #serverless in that almost all development is done on machines that are connected to the internet at all times, so why would you restrict yourself?

It simplifies development, in that all developers need is a cloud account, and a terminal (or similar). In fact, it's possible even to provide them with an instance to do development on.

So going back to CI/CD, assuming all developers have their own Cloud account, then how do you do CI?

Integration happens via infrastructure as code, and into a single cloud account that the CI has access to.

In other words, it's a CI driven cloud account.

If your CI pushed to a #serverless staging cloud account, then your developers will have first tested in their own cloud account, and will know it works (which is far better than "works on my machine") and second the deployment won't happen without passing tests.

So, thinking forward to Continuous Delivery, if your #serverless staging account is controlled via the CI and infrastructure as code, then it's relatively simple to setup a separate production cloud account with the same information.

So that's CI/CD sorted for #serverless. You simply need a manual step in your CI process after testing staging to deploy to production.

And if you want to go Continuous Deployment, then you simply have to automate the manual step. This should be a relatively simple thing to do at this point.

So CI/CD for #serverless is relatively painless if you remove the need for local development

Every developer has a cloud account and uses infrastructure as code to develop their solution
...

...Integrate via git (or similar) and automate testing/deployment to staging

Manually push to production once testing on staging complete

or automate push to production once automated staging tests are robust enough.

#serverless CI/CD

Interestingly this does raise some issues around the future of how to structure repositories and how much code a developer needs to download to be able to develop. Does everybody need to run the entire codebase?

Other questions get raised as well around what development tooling developers actually need. Are we building the right tooling for a fully cloud enabled development team? Probably not at present.

Still, #serverless CI/CD has similarities to a lot of what has gone before, but also has some extra differences to containers/microservices/monoliths that need to be considered.

/THREAD