Coffee break is a part of the art in software development ☕
A roadmap to understand DevOps and automation outcomes and help you implement it.
Prelude
So the last drop of coffee falls into your mug and you are about to start another kitchen conversation.
Your colleagues are gathering to hear the very last news about their personal lives or discuss the latest mail from your boss.
It is for sure the distraction you needed to clear your mind of whatever shit you are struggling on for the last three hours.
Enjoying the warm liquid on your lips and this most needed social reset, you stand ready to reconcile with your computer.
You did a great work during your break !
I am not the one to tell, the green indicators on your screen do.
- Your last work passed code quality analysis, green indicator.
- It has been built without errors, green indicator.
- It passed units tests, green indicators.
- Your software runs in an integration environment, another green indicator.
- All its use cases had been validated, guess what’s green again ?
So it seems the big crash you previously heard of in the kitchen won’t affect you much. Lucky, aren’t you ?
Here come the benefits of automation
While drinking your coffee, all these automations you created were working for you while your team knew exactly how and for how long.
How did you ? Because since you automate, you have a clear vision on these things ! Your automations report KPI such has time to build, files size, tests results, execution environments. Actually you could read this just as you would with the papers, coffee in an hand, donut in the other. 😎
With this level of control you reduce risks of poor product quality but you also work on versioned and shared scripts which you continuously improve in collaboration with your team.
You enjoy your decision to get rid of these old unknown scripts whose had populated your servers two years ago and nobody could remind the purpose or even tell if they still work. Lesson learned, servers are not the place for collaboration.
Of course automation isn’t only about improving productivity, collaboration and predictability.
📘📕Automation is a part of managing the culture in development.
Culture is what unify people and is based on sharing values, knowledge and memories these are definitely things an organisation repository should manage.
When it comes to automate shipping of a software to people it is wise to remove human no valuable and risky actions from the process and work together to improve it.
It may seems legit to have a developer manage a deployment by him/herself as a simple and repetitive task but it is a bad practice both for the team and the product.
Why ?
- First because the person in charge may (v)omit a part of the process.
- Second because it is boring and time consuming (worst combo ever).
- Third because he/she may solve a problem off of radars.
I assume you understand the possible outcomes of the two first reasons but take a look on the third…
It is a bit more vicious in this case, why would you want to know what a developer did if it is done ? There is no more problem if it got fixed once after all.
Yes but no.
You may encounter punctual issues which need to get fixed from time to time and your developer may forget how he/she fixed it first.
The developer who fixed one of deployment issues may also be absent and his/her colleagues unable to operate the deployment.
Last but not least, if you migrate your infrastructures or want to deploy on a new server, you will have to redo what has be done regardless you know you did it or not.
I’d rather say you’ll face costs of poor product management than quality.
Culture makes your teams last and prevent their knowledge spoils, tools or practices that manage culture helps you engage and operate your business for long. (A knowledge base and source code repository as an exemple)
Automation in DevOps
I previously covered some automation concepts applicables in DevOps Operate and Monitor phases in my first article: https://medium.com/@simonmulquin/how-and-why-our-team-improved-its-software-monitoring-and-support-tools-3e3c5778854a
Let’s point now much covered subjects which continuous integration (CI) and continuous deployment are.
Continuous integration is processes you implement from the definition of a feature or service to its built and tested release. See it as an application of lean flow to software development.
Lean Flow is about how items or people we are dealing with in a process move from the first step to the last. Obviously, the intention in Lean flow is to move the item or product through the process as quick as possible, without any risk to quality and customer satisfaction.
As an exemple, the so told item may be a fix, RFC or user story you want to develop and the people are Product owners or developers who you should ease interactions and dependencies from one to the others when processing and sharing the item.
Continuous integration implementations consists in collaborative tools and methods upstream automated processes designed to build, test and release your softwares.
In the same idea, continuous deployment will cover a set of practices to deploy releases on an operating environment.
Let’s take a look inside.
Continuous integration: Plan
For me, integration starts at the very moment a stakeholder issue a new requirement, bug or constraint.
Your PO or whoever manages business change will be responsible for analyzing the request and choose to push it or not in development.
Actually maybe your processes includes the development team at this point but I believe user requests are often pre-processed in bigger organisations so I will assume the input to continuous integration from a developer view is a well shaped user story in a product backlog.
Once the development team is aware of a new item in the backlog, they can challenge it in collation with the whole team on a dedicated, easy to recall, workplace.
It is the first step you may want to automate, as an exemple by configuring notifications on your backlog and so avoid developers being interrupted by a PO or don’t see the new backlog item.
You have to assess you backlog items development readiness. It may seems obvious but you shouldn’t rush the implementation of practices your team don’t understands or needs.
The backlog item could implement things such as prioritization, budget validation, wireframes, process and data models, licences and api docs, … Where some developers don’t need much than a few simple words depending of their tasks.
I will probably write another article on backlog refinement later and move it in, move along.
The point is that at the end of Plan phase, the dev team know what to do, why and maybe when.
Continuous integration: <Code/>
This part will be about code validation more than coding itself.
So your developers had processed the items and developed or fix features.
Before they take their coffee break, each commit his/her newly written code on the source code repository.
They are many source code repositories you could implement. Your only constraints are they should handle the VCS you use (eg: git, mercurial) and CI, here are some: Gitlab, Github, Bitbucket, Upsource, …
The scenario mentioned in the intro just started to run. Your SCM tools are triggering automations everywhere !
Here is an exemple of what could happen while your devs drink coffee (or tea, tech people are inclusive)
First a tool (let say Jest or Jasmine) runs units tests and output a report (a fancy green/red thing for you, a scary JUnit file for your tools), that tell you if and where your code break.
At this point, if you have well managed your code versioning, you also know what precise code change breaks your software.
After this first step, your systems may run code quality analysis (eg: with ESlint) and still report. Some are also apply dependencies management policies such as looking for versions with known vulnerabilities. (My own team decided not to implement this so I am afraid I can’t say much)
NB: You may want to set up ask for review notifications and prevent bad design or architectural assumptions to be pushed in the source code by letting the team, architects or tech lead inspect it. My team had a POC where we handled this trough pull request which were reviewed and merged before any automation but we didn’t implement it so I can’t advocate we did it a good way although many say you should implement code reviews.
Continuous integration: Build
Once you processed the code is the time to build.
We may see the previous tests as an anticipated part of Test phase but, in languages I know, we actually didn’t test anything operable at this point.
To build your app may means you transpile your code to a files bundle, compile to an executable file, a docker image or anything that is deliverable to production.
You will find lot of articles telling you how much you will love Docker and why but I’d religiously say it siege in the hall of the best things that has been created for both IT folks and users.
Well done, you are ready to ship your software !
Continuous integration: Test
But wait… Did your unit tests validate any feature ? How to know if it is ready to handle all the use cases it has been made for ?
What you need now (and I bet you do), is end to end testing.
End to end testing is about validating multiple user scenarios by running action from different places of your systems. You are then able to describe an event (entity creation, service unavailability, update, migrations, attack,…) and the desired behavior of your systems which can be other events, response time, UI responsiveness, …
Implementing it is easy (has I know from web development, I am sure it is less when you test industrial products for aerospace) but you should start small, testing your form input is well processed by analyzing it’s behavior with database queries or accessing a browser’s DOM as an exemple.
If you want a more interesting challenge, try to test the content of a mail by implementing a local mail server in your integration environment and fetch a previously sent mail with imap to validate and use it’s content. This is actually what I deal with at the moment to test users registration and first connection… 😇
Now you have built and tested one or multiple components of your system, you are ready to release ! Actually I hope you are still drinking your coffee and you have a great conversation in the kitchen.
Continuous integration: Release
Using docker with my team, we publish tested images on our organisation’s Docker registry and simply tag all our images with the same version ID so another script could load and install all these images ensured to work together.
We can do that because we currently work on a set of softwares which will be delivered in other organisations, we would obviously not if we have to validate our whole organisation’s informations systems.
At any moment, we can load a working version in acceptance, and tag it with a public, prod ready, semver tag once our PO and users validated the set.
I would define a release something that is ready to load and install, (self)documented, published on the adapted platform and notified to stakeholders.
The platform(s) could be mobile apps stores, Github, Docker hub, your website or any storage accessible to your ops, users our clients.
Your may consider to define your releases with your stakeholders.
Continuous deployment
Continuous deployment is often seen as triggered by a successful CI process which its release is input to an actual deployment process.
Actually it is just some processes you implement to continuously deploy some artifact in any environment it is needed.
As an exemple,you could either choose to deploy an official release in production or to deploy some dependencies in integration-acceptance when running end to end tests.
The so called artifacts could be databases, services, licences, certificates, or actually anything made of bytes that as a signification in your architecture.
On web apps field, these artifacts are deployed on servers, continuous deployment may cover SSL certificates updates, databases migrations, service or container start,…
I’d say even if web apps actually improved the way we deliver softwares to users and are the perfect match with continuous deployment practices, you could also implement it for other applications.
So you may want to deploy on formatted devices you will actually sell (dongle, raspberry, microelectronics, disks…) , make your desktop apps fetch for new releases at start, …
If we speak of web apps your deployment processes could also be used for orchestration and/or horizontal scale deployments which is still more “continuous” that the way we will implement it in development.
Cause yes, this will be the time to end your coffee break or at least if you are PO or project manager. Why ? Because we don’t want or processes to overwrite an environment that is still being tested or which update has not been planned. This would lead you and you testers to lose de sight of what has really been tested and on which version.
This said you can help you PO by giving him/her a way to trigger a deploy (do not if you cant’ properly monitor deployments), it is as simple as a button when you processes are up to run.
I am sure we could win on this situation and propose a no lock process in some situation but it would necessitate a real simple context or insanely mature teams and systems.
If you could do it without risking to break running processes such as transactions or sockets, mind to implement blue green deployments to enhance your services availability and let your devs more time to drink coffee.
NB: Both CI and CDep could be implemented such has pipeline, plan, scripts or whatever you call it in the appropriated softwares. (eg: circle-ci, team city, gitlab ci, …) I implemented Atlassian Bamboo in my current organisation for the great environment using it with Jira and Bitbucket but it is to say it is a bit immature at the very moment unless they did a great step ahead with Bamboo-specs. I hardly recommend that the tool you will choose support code as configuration and you use it rather than GUI.
What about continuous delivery ?
For me continuous delivery is about taking words from mouth to bring running softwares in hands and it is actually easier than hat and rabbit magic.
Once you released and deployed, you are not far from getting the rabbit ou of the hat, you will have to manage change for your clients or your organisation business units.
This could be achieve working with sales teams, help desk, actual users or business experts on the implementation of your software in your users habits and teaching them how and when to use new features.
While DevOps mindset understand the outcome of getting rid of silos, it is described as a combination of dev and infra teams/skills and I’d say it’s a limited way to see it.
I personally see a legitimate place for users in Operate, Monitor and Plan phases, although they are still users and will use either a software or a practice you implemented for and maybe with them, you shouldn’t forget about their interaction with IT teams.
You should mind:
- How will you Operate your software including support tools and practices, how your manage incidents and communicate with users(FAQ, helpdesk, self documented software, mentorship, manuals, logs exports, chatbots,…)
- How will you Monitor users requests as well as IT components (surveys, ideas box, voted tickets, process owners, SPOC PO, …)
- How will you Plan involving your users(business analysis, users scenarios, interviews, cards games,
There you actually go for continuous delivery and close the loop.
This said, please don’t ever try to put a devsecusersops on the market, we play IT not dinosaurs… 🙄
Well devsecops is actually an existing buzz word (such as devops), I guess everyone wanted to be a part of this beautiful thing but hey it’s just like feminism, it put any gender identity on an equal stand not a scrabble board !
Different approaches and means
There are many conceptions on what continuous things are, some may say:
- plan or release isn’t part of integration;
- continuous deployment is enhanced CI;
- developers shouldn’t care about delivery or even users (they don’t show up on medium);
- they segment continuous integration, testing, delivery and deployment;
- continuous deployment is ment to production environments only…
- it is a step after continuous delivery which goal is to deliver a release that will actually be deployed to users (managing deployments in IT management actually lead to change management and so interaction with users)
So asking what it is you’ll have multiple answers, multiple truth just like you asked what love is. Baby, don’t hurt me…
I believe each conceptions are valuable strategies adapted to different companies cultures and architectures to achieve they own goals by applying lean to software development. At the end we all do the same kind of thing and ou first priority isn’t to give it a name.
When we design these processes, we lever on responsibilities segmentation, ease interactions between stakeholders, reduce waste and costs. This article shared you my own conception which has made its proofs on the web apps field and I assume could do far more because of its simple design.
What’s next ?
Now you know when to use automation in your development practices. There are plenty of blog posts on each these practices that can help you implement them for your own needs and environments.
Automation is about sustainability so don’t forget that each your automated processes should be versioned, monitored, and shared with the organisation.
I’ll enjoy if you share your impressions and challenge what I wrote.
Enjoy your next talk on automation within your coffee break 😉☕
Credits
Photos serve illustration purpose and are taken entirely out of context if you ever mind.
I unfortunately had to crop and lower the quality of some of the credited Unsplash images in the article. Go and check the artists work if you’d like to see the originals.
Many thanks to them to let all their great content accessible to little blog writers like me. 🙏
