Getting started with Sonatype Nexus Repositories.

All you need to know about Nexus Repository to begin with!

Nexus Platform is what makes the overall software practice more efficient and to make the software development to pertain the modern software processes.  This also helps the developers to make better decisions.  Lets take a look at how and where Nexus Repository plays an important role.

Developers are at the beginning of the process they will checkout their code into the source control management tools like git, mercurial. This will be stored as pre-built binaries and the build systems then the binaries will be fetched by the repositories residing inside the public repositories like maven central, pmj. So after all these changes, the build manifest is again pushed back to the source control together with the source and build manifest.  This will automatically trigger a build in the CI system.  At this point this build also collects the binaries from the repository manager, assuming that this has passed all the testing phases the final bits are then again pushed back to the repository but bits and pieces then run in a loop until it is packaged into a final application.

The final applications are fetched from the repository by a deployment automation tool like Jenkins, Ansible or Chef.  This will push the deployment through multiple phases of testing such as Development, Test and stage and ultimately this will reach production.  As shown in the Figure 01 above the process which includes source control, developers and build is called the Continuous Integration.  The process which is involved with the deployment is the Continuous Delivery.  This is the basic modern software development life-cycle in a nutshell.  As the goal of modern software development is  to get more value to the market quicker, There we as Devops engineers should step in with the DevOps native processes.

The feedback from the development team is essential here as they are on the frontline deciding what and what components not to use, this will save up time for rework and contention later.  Then it is important to decide which components will be eliminated, mostly this will be components that are initially against the business model or which have known vulnerabilities.  The analysis done during the CI phase will allow to take timely decisions upon the application that is being built and provide feedback to the development team.  When integration test failures are discovered and they are rectified the system will only contain only known and healthy components.  

• Unhealthy and vulnerable components blocked when accessing the public repositories 
• Only trusted components are welcomed into the repository
• Policy enforcement should be done during the Build (shown in figure 02)

When checking for compliance at the CD phase this is the key when actually being pushed into the production.  When being released into the production environment it is necessary to evaluate that the original build hasn’t changed and nothing has changed.  Policy enforcement should be carried out during the Deployment phase too.

When speaking about where the Nexus Repository, looking at the big picture the Nexus Repository sits in the middle of the figure 03.  Nexus firewall sits in the top of the repository and blocks incoming vulnerabilities and provides monitoring to the repository.  Then the Nexus life cycle which provide detailed information and policy enforcement in the IDE build deployment and continuous monitoring of the deployed application by integrating with the tools which already resides in the pipeline.

We will look into deep with Nexus Repositories in the future posts. For More DevOps related posts click here