CI/CD get-to-know-you questions
07 Mar 2023
Here are some questions I recently found myself scheduling a meeting to ask the director of a team of developers who’d like to modernize their CI/CD practices.
Interestingly, there are a lot of blurred lines and interdependencies between “architecting CI/CD” and “following classic software application architecture patterns.” For example, you’ll probably see Martin Fowler weighing in either way! (Just recently, I read an article where he warned that while architecting your applications for feature flags can help you keep your Git branching strategy as tidy and rapid-release-oriented as Silicon Valley … congratulations: you’ve effectively just introduced a database to keep up-to-date in addition to your Git-tracked codebase. Hope you’re ready.)
In other words, these questions feed into a lot of “it depends” from me about CI/CD.
Environment count
How many environments (e.g. “production,” “staging,” “dev,” etc.) does each of the applications you’re rearchitecting this year have?
Is that still the number you’ll be looking for when you finish migrating the applications to your new cloud resources?
Environments as code
Does your application architecture lend itself to having just 1 Git-tracked codebase no matter which “environment” your application is being deployed to? (e.g. Perhaps the frontend can find out what environment it’s running in by querying some sort of key-value store and dynamically builds its connection parameters to the backend.)
Or have you traditionally kept separate pieces of code for each environment? In this case, “piece of code” might mean:
- Git repositories
- folders within a Git repository
- long-lived Git branches
- build+deploy pipeline configuration files
If you’ve been separating things, do you have any sense of whether your applications are inherently nit-picky enough that refactoring them to more single-track codebases would be out-of-scope for the migrations you’re planning this year?
Or are you enthused to refactor them and seeking connections with others who’ve done such refactors?
CI/CD pipelines
What do you and your developers love about your current Git-based build+deploy pipelines? Hate?
CI/CD workarounds
Do you or your developers ever make end-runs around existing Git-based build+deploy pipelines? For example, by using manual clicky-buttons in Visual Studio instead? Why or why not?
Automated testing
Do your existing Git-based build+deploy pipelines – or local-IDE-clicky-button-based habits/tooling – include any auto-fail mechanisms if unit / integration / regression tests fail against the code you’d like to build+deploy?
Or do you always deploy built code onto some sort of running server (perhaps a nonproduction one) and have people manually test it before deciding that the codebase is good enough for production?
Or some of both?
Other testing and QA
What else goes on in your team for QA / testing that influences how you develop, build, and deploy?
Workload
How many developers do you have?
How many applications are you developers supporting? 5? 20? 500?
What’s your cadence of code-changes like per application, typically?
Code review
What are your peer code review processes like right now?
Do they have any impact on any of the following?
- Your Git branching strategy
- Your Git-based build+deploy pipelines
- Cultural habits your developers practice
Logging and monitoring
What is the state, within your applications that you’re planning to migrate, of making your codebases include callouts to logging tools?
Are you planning to refactor them to point at new logging tools or leave logging alone?
Are there any automations you dream of building upon the results of monitoring those build-time and runtime logs?
Misc
Etc. etc. etc.
I’d love to hear about – and maybe tour examples of – anything else you can think of that feels like it might have an impact on choosing approaches to configuring CI/CD that work best for your codebases and teams.
