Modern Network Development Life Cycle (NDLC)

Modern NDLC

With new tools come new processes and procedures. Below is a high-level overview of the modern NDLC using all the tools introduced above. This includes a simple branching strategy. The organization should decide on its own branching strategy. For example, a new branch for every change, no long-lived branches, and no branching beyond two branches. For now, we will adopt a new branch per change approach with one level of branching.

Here is an example of the modern development lifecycle:

1. Create a repository specific to the environment. Examples include Production, Lab, Development.

2. Create a master branch. The master branch will be what is considered tested, approved, current, golden configurations, and code.

   • Never develop or make changes directly inside the master branch.

   • Use Git commits and pull requests to merge changes into the master branch.

   • Playbooks should be executed from the master branch.

3. Create a working branch. All changes are performed in the working branch. Playbooks are tested and validated, possibly with check mode and verbosity, in this branch.

   • Commits from the local repository should be made often. This prevents local work from being lost and ensures the ability to collaborate on branches.

   • Pull request to merge changes into the master branch. An entire workflow can be created from the pull request, various QA and approvals can be done, and changes can be merged successfully into the master branch.

4. Clone the repository locally using git clone, and bring the repository down to a local Windows or Linux machine. This is extremely portable provided Linux and Ansible are installed.

5. Change to the working branch using git checkout.

6. Make changes such as modifying existing files, creating new files, or deleting files.

7. Use an editor to save local changes and stage changes using git add.

8. Commit changes using git commit. Make sure to add a meaningful comment to the commit.

9. Push changes using git push. Make sure to synchronize changes with the text editor. This finalizes the commit and pushes the files into the central repository.

10. Create a pull request to merge the working branch into the master branch. A full workflow can accompany this pull request that could require reviewers and approvals.

11. Version and change control are made simple through the use of Git. All changes can be referred to by their unique pull request. Each pull request consists of Git commits. Using Git makes roll-backs and troubleshooting problematic changes easy.