Artifact repository, application pre-deployment and staging – Developer Perspective

By Narayanan Ramachandran, Lead Developer, WATI

The Software world is moving at a rapid pace like never before. It is more shifting towards, what was once considered inevitable, Servers, Code and the whole Application Life cycle is diminishing, a serverless, code less, microservices based architectures. This shift puts a lot of responsibility on the developers, that they not only worry about the piece of code that they write, but need to think about the overall system, the repositories, application pre-deployment and staging, before it gets released to production. Developers are also responsible for the speed in which the application is release to the production without hampering the other microservices or other pieces of services in the overall project.

With DevOps Automation – Continuous Integration (CI) and Continuous Deployment (CD) makes production rollouts faster. Failures are detected upfront due to continuous feedback. While the developer always think about the production environment and tightly coupling the application’s properties with the production server, the artifacts becomes unusable in other deployment setups. Also if the Pre-Production or Staging setup is different from the final Production setup, it makes the artifacts unusable. So as a developer one needs to keep in mind of decoupling of artifacts and application properties so that you can build once and deploy across multiple server environments.

Being a developer for more than fifteen years, adapting to the new way or paradigm shift is difficult for me. As a developer from the Client Server to n-tier programming to web services, learning has been continuous. While I am willing to learn new things always, when our organization wanted to adapt to devops, at first I was reluctant. When given the charge of being the change manager of the project from the Infrastructure, development and operation, I was forced to learn DevOps first before I implement. I learnt about Jenkins, Git, Maven, Chef Zero, OpsWorks, Rundeck, Talend. I understood the importance of DevOps how important and difficult it is to maintain the quality of a product that is being developed by a team of developers, testers, operation people and infrastructure managers. My exposure to DevOps completely changed my view of the life cycle of software development.

An artifact repository organizes and manages binary files and their metadata in a central place. Artifact repository is important as teams get larger and the use of components, assemblies, and microservices becomes increasing and difficult to manage. When development teams lack a repository manager, they face several challenges. When teams don’t have an artifact repository, they often rely on file sharing services to store their build artifacts. This makes it hard to track the versions of artifacts and their usage. Complex binary dependencies need to be delivered into the CI/CD pipeline by an artifact repository that has high-performance servers.

A stage is a logical and independent entity that represents where you want to deploy a release generated from a release pipeline. Understanding of how to divide your release pipeline into stages in your DevOps CI/CD process is essential for the developers. Development, Staging, Production – As new builds are produced, they can be deployed to Development. They can then be promoted to staging or pre-deployment, and finally to Production. At any time, each of these stages may have a different release (set of build artifacts) deployed to them. This is a good example of the use of stages in a release pipeline.

If development and test environments don’t match the production environment, it is hard to test and diagnose problems. Therefore, keep development and test environments as close to the production environment as possible. Make sure that test data is consistent with the data used in production, even if it’s sample data and not real production data (for privacy or compliance reasons). Plan to generate and anonymize sample test data. Ensure that all authorized team members can provision infrastructure and deploy the application.

Automate deploying the application to test, staging, and production environments. Automation enables faster and more reliable deployments and ensures consistent deployments to any supported environment. It removes the risk of human error caused by manual deployments.

The Author is a lead developer with West Advanced Technologies Inc. and has worked with many large projects implementing DevOps from a developer stand point.

Menu