Chapter 14 — Software engineering
Lesson map
Lesson 14 published. Map, example, EX040.
flowchart TD
N0["Learning outcomes"]
N1["14.1 Configuration as code"]
N2["14.2 Review"]
N3["14.3 Testing"]
N4["14.4 Deployment"]
N5["Change review checklist"]
N6["Environments"]
N7["Documentation as part of the change"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX040"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["14.1 Configuration as code"]
N2["14.2 Review"]
N3["14.3 Testing"]
N4["14.4 Deployment"]
N5["Change review checklist"]
N6["Environments"]
N7["Documentation as part of the change"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX040"]
[Learning outcomes]
|
v
[14.1 Configuration as code]
|
v
[14.2 Review]
|
v
[14.3 Testing]
|
v
[14.4 Deployment]
|
v
[Change review checklist]
|
v
[Environments]
|
v
[Documentation as part of the change]
|
v
[Worked example] --> [Exercise EX040]
Learning outcomes
You will (1) manage configuration as code; (2) review changes; (3) test configurations.
14.1 Configuration as code
Firewall policies can be kept as text in version control, with changes reviewed before deployment. This gives history, review and rollback.
Configuration as code means keeping device and firewall settings as text files in version control, rather than editing devices by hand. Every change is then recorded with who made it, when and why, and earlier versions can be restored. Templates generate consistent configuration for similar devices, which reduces drift between offices. The approach also makes review possible, because a proposed change appears as a readable difference that colleagues can inspect before it reaches production.
14.2 Review
Each change is reviewed by a second engineer against the needed-flows list.
Peer review means a second engineer reads every proposed change before it is applied. The reviewer checks that the change does what its description says, does not open unintended access, follows naming conventions, and has a rollback plan. Review catches mistakes the author cannot see in their own work. Keeping review comments with the change record also documents the reasoning, which helps later engineers understand why a rule exists and whether it can be removed.
14.3 Testing
Automated tests evaluate synthetic flows against the policy and check expected allow or deny results.
Configuration can be tested before deployment. Syntax checks confirm the device will accept it; policy tests confirm that required flows are allowed and forbidden flows are denied, using a list of expected results; and lab trials with synthetic traffic confirm behaviour on real equipment. Automated tests run on every change, so a mistake that would block a critical service is found in minutes in the lab rather than by users on a Monday morning.
14.4 Deployment
Approved changes are deployed in windows, with automatic backups of the previous configuration.
Deployment applies an approved, tested change to production. Safe deployment proceeds in stages, starting with one low-risk device or office, checking that services work, then continuing. Each step has a defined rollback, and the deployment record notes the exact version applied. Automating deployment from version control removes manual retyping, which is a frequent source of errors, and guarantees that what runs on the device is exactly what was reviewed.
Change review checklist
Reviewers use a short checklist for each policy change: does the change match an entry in the needed-flows list; is the source and destination as narrow as possible; is there an owner and a reason; does it include a test; and is there a rollback. The checklist turns review from a general impression into specific questions that can be answered yes or no. Kofi tests it on ten historical council changes and finds that four would have failed on narrowness, which suggests the checklist would have prevented overly broad rules.
Environments
Changes are first applied to a lab firewall with the same software version and a copy of the policy. Synthetic test flows confirm behaviour before production. Kofi builds the lab from spare equipment provided by the council. A lab never perfectly matches production, so he documents known differences, such as fewer interfaces, and treats lab success as necessary but not sufficient. Production changes are still scheduled carefully and verified afterwards with the same tests. Each known difference is reviewed whenever the lab or production equipment changes, so the list stays accurate.
Documentation as part of the change
A change is not finished until its documentation is updated: the needed-flows list, the diagram if zones or links changed, and the decision record if the change reflects a new design choice. Kofi includes documentation updates in the review checklist so they cannot be skipped. Out-of-date documentation is a common cause of later errors, because engineers trust diagrams that no longer match reality and make changes based on them. Reviewers reject a change whose documentation is missing, just as they would reject one whose tests fail.
Worked example
A test asserts that guest→servers:443 is denied; a change that broke this fails review.
Synthetic case. Tests are synthetic.
Errors and limits
Tests only cover cases written; maintain them as requirements change.
Exercises
- EX040 — Version control benefits. List three benefits of version-controlled policy. Rubric: 3 = history, review, rollback;; 2 = two;; 1 = one;; 0 = none.
- EX041 — Policy test. Write one policy test case. Rubric: 3 = flow and expected result;; 2 = partial;; 1 = vague;; 0 = none.
- EX042 — Test limits. What is the limit of automated policy tests? Rubric: 3 = only cover written cases;; 2 = incomplete;; 1 = vague;; 0 = none.
Synthesis
Treating configuration as code brings software discipline to networks.
Continue studying — chapter 14 of 50
← Chapter 13 (draft) · Course chapter index · Chapter 15 (draft) →