Dabbling Seriously

Code, Coffee, and other Stuff.

Desiderata for a SDLC Pipleline

I’ve been thinking about what an ideal software development life cycle tool chain would look like. Obviously to start with, you would want to be able to cut code. Then, you’d want to be able to build it, and share it with other developers and keep track of the history of things that you’d done. When you’re cutting code, you might be able to refer to some acceptance criteria, that you can write unit tests on and that a requirements analyst or test analyst can also understand, and that can be run automatically whenever you change the software, and those people would also like to be able to specify things without you. You would want to be able to have a conversation about requirements if change is necessary or if there is a disagreement. When you change code, you would want to be able to have a conversation with the test analyst about which requirements or test cases might be affected. Imagining the code is correct, you’d want to be able to release it and then potentially deploy the code, or your customers may want to deploy that code on their own terms. Once deployed you’d like to be able to monitor the what’s running in production, and when problems or crashes occur you’d like to know about that, and when that happens you would like to have some way of managing communication with your customers – when changes occur, when something is broken, when something is fixed, and when a customer is affected. Customers with feedback such as bugs, problems, suggestions could be prioritised and turned into work items that the developers could look at, or the test analysts might try to reproduce.

If all of these things work well together you could potentially lower the cost of ownership of  your software and process.

Where I work we have several of these pieces in play, some of them are working well, and some don’t exactly exist. We use visual studio for our development environment and  visual studio team services with git to share our code with one another. Our requirements and bugs are listed in visual studio team services, but our requirements are in a variety of different mediums making them difficult to reference. Google docs, and Confluence. Our builds run on visual studio team services in most cases, but we’ve also been using team city and build kite, and our deployments are done using octopus deploy. Currently our BAU monitoring is done using Splunk, and our crash diagnostics use Sentry. We’re still in the process of implementing a service desk tool. Integration is still an ongoing process.

What do you think? Have I forgotten anything? I’d love to hear from you.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s


This entry was posted on January 19, 2018 by in CodeProject, coding, programming, Software, work.


%d bloggers like this: