This is part 3 of a 4-part series of articles based on discussions at the LondonCD meetup group on 12 June 2017. The other posts are linked at the end of this article.
Applying the principles and practices of Continuous Delivery for new software is fairly straightforward (at least, until you deal with data and databases). However, existing “legacy” systems that were built without many automated tests and without much concern for repeatable deployments of discrete functionality pose a challenge for moving to Continuous Delivery.
This is part 2 of a 4-part series of articles based on discussions at the LondonCD meetup group on 12 June 2017. The other posts are linked at the end of this article.
Continuous Delivery for web applications is (in 2017) largely a solved problem but where data and databases are concerned, Continuous Delivery becomes more difficult (I have written quite a bit about Continuous Delivery and Databases on the Redgate Simple Talk website – worth a read if you’re interested). In the meetup, we explored some of these challenges and some solutions to Continuous Delivery for databases. (Thanks to Alex Yates of DLM Consultants for his expertise in facilitating the discussion!)
This is part 1 of a 4-part series of articles based on discussions at the LondonCD meetup group on 12 June 2017. The other posts are linked at the end of this article.
How do we continuously address security concerns with modern software development? That was one of the questions we discussed and tried to answer at LondonCD meetup group on 12 June 2017. “The yearly PEN test is dead!”, said one person, meaning that reliance on an infrequent, specialist test to address all security problems is simply not good enough any more.
I have recently read (and re-read) several books on Chef in order that I can recommend books to clients who are starting with infrastructure automation (and to remind myself of the more obscure uses of knife, encrypted databags, and so on). In this post I comment on these books:
- Chef Infrastructure Automation Cookbook by Matthias Marschall
- Managing Windows Servers with Chef by John Ewart
- Test-Driven Infrastructure with Chef (2nd Edition) by Stephen Nelson-Smith
- Automation Through Chef Opscode by Navin Sabharwal and Manak Wadhwa
Summary: read Chef Infrastructure Automation Cookbook for a good introduction to Chef on both Linux and Windows; read Managing Windows Servers with Chef if you manage many Windows machines; but most of all read Test-Driven Infrastructure with Chef because without a test-driven approach your infrastructure code will rapidly become tangled, unsupported, and obsolete.
I recently posted a review of Patterns for Performance and Operability by Ford et al on the SoftwareOperability website. I think that this book is exceptionally useful in its treatment of both performance and operability, and anyone who cares about how well software works in Production should buy and read a copy (there are paper and eBook editions).
Two other reviews might be useful too: my colleague Anant East (Head of Architecture and Infrastructure, thetrainline.com) wrote up a detailed review of Patterns for Performance and Operability on the tech blog at thetrainline.com, and I posted a short review on Amazon.
I attended a workshop at DevWeek 2012 led by Neal Ford (@neal4d) on Continuous Delivery (CD). The day was excellent – Neal is a really engaging presenter – and I took copious notes, even though I’d already read most of the CD book. Fifteen months later, I thought it would be interesting to see how my notes from Neal’s workshop compared with my experience of Continuous Delivery, both within my job at thetrainline.com, and also in conversations with other people, particularly the good folks in the London Continuous Delivery meetup group.
The tl;dr version: go attend one of Neal’s excellent CD workshops, but be prepared for the challenges with Continuous Delivery to be much more social/organisational than technical. Continue reading
This article first appeared in Software Development Practice, Issue 1, published by IAP (ISSN 2050-1455)
When raising log events in code it can be difficult to choose a severity level (such as Error, Warning, etc.) which will be appropriate for Production; moreover, the severity of an event type may need to be changed after the application has been deployed based on experience of running the application. Different environments (Development (Dev), User Acceptance Testing (UAT), Non-Functional Testing (NFT), Production, etc.) may also require different severity levels for testing purposes. We do not want to recompile an application just to change log severity levels; therefore, the severity level of all events should be configurable for each application or component, and be decoupled from event-raising code, allowing us to tune the severity without recompiling the code.
A simple way to achieve this power and flexibility is to define a set of known event IDs by using a sparse enumeration (enum in C#, Java, and C++), combined with event-ID-to-severity mappings contained in application configuration, allowing the event to be logged with the appropriate configured severity, and for the severity to be changed easily after deployment.