netdevops | Hands-on with NetDevOps | Continous Integration library

Open a terminal window (ie. [putty](https://www.putty.org/) on Windows or terminal on OSX) and ssh to your devbox with the following credentials: developer/C1sco12345. Once in, clone the repository that includes all required files to build the setup into your devbox. With that, your sandbox devbox includes now all required info to start building the environment. setup.sh will start and configure your Version Control Server, a GitLab instance inside a Docker container running in your devbox. The process will take like 5 minutes, so check this out in the meanwhile. <p align="center"> <img src="imgs/9pendulum2.gif"> </p>. Once your terminal shows the process is finished, you may check with docker ps that your GitLab containers are running, and how they offering their service in port 80. Please point your browser to [http://10.10.20.50](http://10.10.20.50/), the IP address of your devbox (default port 80), and check that you can access the HTTP interface for your new GitLab service.
Now that GitLab is ready, go back to your terminal and let’s run the script to setup the complete CICD environment.
Launch the required VIRL simulations for two different environments: test and production
Start NSO
Import test and production network configurations from VIRL to NSO
Synchronize devices configuration from NSO into VIRL simulations
Create a new repo in GitLab and initialize it locally in your devbox
Create locally in devbox the prod and test git branches and push them to GitLab
List the status of VIRL nodes in production and test
To experience and demonstrate the full NetDevOps configuration pipeline, you may want to setup a local development environment where you can test proposed configuration changes before committing and pushing them to GitLab for the full test builds to occur. This is a completely optional step you might want to skip if you are not interested in testing locally. To complete this step you will need to have a few local pre-requisites setup on your local workstation. 1. Common software: install Java JDK, python and sed (brew install gnu-sed in OSX). 2. [Network Service Orchestrator](https://developer.cisco.com/site/nso/): in order to test the configuration pipeline locally, you’ll need to have a local install of NSO on your workstation. Furthermore, you will need to have the same versions of NSO and NEDs (network element drivers) installed as the DevBox within the Sandbox. Using different versions may work, but for best experience matching the versions exactly is recommended.
[Network Service Orchestrator 4.5.3](https://software.cisco.com/download/home/286319308/type/286283941/release/4.5.3?i=!pp)
Cisco IOS NED 5.8
Cisco IOS XE NED 6.2.10
Cisco NX-OS NED 4.5.10
We like robots because we can offload repetitive & tedious tasks to them and they will be happy about it! Well, maybe happy is not the right word…​ let’s say they’ll do what we need 'em to do and not get bored in the process. These robots, or bots for short, might offer different ways to interact with them. We, as humans, normally interact with machines using our fingers as the output interface when typing a request in a keyboard, and our eyes as the input interface when reading in a screen what is the outcome of that request. Those requests we type might be formatted in 3 different ways: 1. Using our bot’s native language, but we’ll need time to learn it 2. Using our own native (natural) language and have some logic map what we mean to the bot’s native language 3. Something in-between, an easy-to-use and intuitive, but structured, way to interact with our bot. No matter what option we decide to use, the final goal will be the same: to have our bot receive requests and translate them into whatever underlying logic is required to interact with relevant infrastructure to perform them. The easiest way to get started is to go with option #3 and leverage bots to interact with whatever platform APIs we work with. But what application can we use to communicate with our bot? It might be using SSH to a remote system from a terminal window, sending an SMS or an e-mail message, or even a proprietary app in your mobile terminal. But how convenient would it be to talk to the bot using the same messaging app we use to communicate with our colleagues at work? For example [Cisco Webex](https://www.webex.com/). Operating infrastructure systems with bots via messaging applications is called ChatOps. <p align="center"> <img src="imgs/220robot.jpeg"> </p>.