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"


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.


• • •

Missing some Tweet in this thread? You can try to force a refresh

Keep Current with Paul Johnston 🌍 need: NED, advisory, consulting

Paul Johnston 🌍 need: NED, advisory, consulting Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!


Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @PaulDJohnston

Sep 7, 2018
There's a whole lot of people online saying they still look things up or make stupid mistakes when coding after X years in tech.

I definitely still do. I'm not perfect. Documentation is important. I look up stuff that is easy all the time. I make really dumb mistakes.
But I've also spent over 20 years coding in multiple different languages and doing various different roles.

I haven't always been someone that writes code.

Writing code is not what I do that adds value.
Someone who writes python or go day in and day out should remember a lot of python stuff because it'll become second nature.

But I wouldn't expect them to be able to walk into a board meeting and explain the product roadmap to an investor either.
Read 8 tweets
Aug 18, 2018
Thread: My wife was at the supermarket today picking up some bits and pieces and she got chatting to the young guy at the checkout.

They had a chat...
He had decided after school not to go to University and had been working there for a couple of years but was excited now because he was about to go.
He'd looked at the options after school and seen it as something that wasn't for him. But having worked for two years he decided that the job options weren't that good so decided to look again.
Read 13 tweets
Aug 14, 2018
Gave my Dad an echo dot yesterday. He has macular degeneration and I thought it might help. Installed a big company's skill for him to help with trains (my parents can't drive any more) and watched the interaction.

It was terrible.

Sometimes tech just doesn't get it
I completely understood the interaction and the questions.

A 70+ yr old?

He asked a perfectly reasonable question about when the next train from X to Y was and the response was

"Do you want to plan a journey?"

Which was a bit confusing because he'd just said that
There was no "I didn't quite understand" or anything like that.

Our voice interactions should default to "my fault... Didn't understand... Sorry" and not respond with questions that seem confusing

If the person says "I just said that" then you've got it wrong
Read 4 tweets
Jun 23, 2018
Well, Germany are rubbish this year #WorldCup #GERSWE
Spoke too soon. Sweden are trying very hard to lose #WorldCup #GERSWE
Like REALLY hard #WorldCup #GERSWE
Read 4 tweets
Apr 16, 2018
THREAD: A good practice is for each AWS Lambda function to do one thing rather than bundle all functionality into one function.

A quick answer is that the smaller the Lambda function, the faster it will load and the quicker it should run (depending on libraries etc), but that's very simplistic
Let's take a slightly more businesslike view of #serverless
Read 20 tweets

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!


0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy


3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us on Twitter!