Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

The Developer's Role in Enabling Continuous Integration and Deployment

DZone's Guide to

The Developer's Role in Enabling Continuous Integration and Deployment

Continuous integration and deployment have become an essential part of DevOps, but what can developers do to strengthen this process? Read on to find out.

· DevOps Zone ·
Free Resource

The need for DevOps innovation has never been greater. Get the results from over 100 business value assessments in this whitepaper, Digital Darwinism: Driving Digital Transformation, to see the positive impact of DevOps first hand.

With the software world moving towards microservices and domain-driven architecture, the actual amount of coding is reducing. But, with this architectural shift, responsibilities are increasing, like how fast your application can be released to production without hampering other microservices in your architecture. Continuous Integration (CI) and Continuous Deployment (CD) play an important part in achieving faster production rollouts as failures are detected upfront with continuous feedback. We have many articles talking about what CI/CD is and why it is required. This article mainly focuses on the role of application developers in achieving CI/CD.

A common mistake made by developers is coupling application properties with the production server. This makes generated artifacts very tightly coupled to only one server environment, resulting in an anti-continuous integration and deployment pattern. Once the artifact is baked with production properties, that artifact is of no use for other deployment setups, like CI, staging, or pre-production. Let us see an example to understand this anti-pattern and how can we overcome it.

Consider this: a Java-based application using Spring Framework for bean management needs to talk to a database to fetch configurations. The properties of the database which needs to be connected are present in the resource folder, in a property file name - say, database.properties - one of the property is the database URL, and the value of this URL contains a hardcoded value pointing to the production server. This application is build using maven tool and artifact generated is say application.war which is deployed on application server say Tomcat. Generally, people edit these properties with values pointing to their local system and run the application which is understandable from the perspective of testing it locally and not committing these edited properties to the actual source code. But, these practices do not help in filling pieces of continuous deployment in a different environment. Now let us see how we can overcome this problem.

As a developer, one needs to keep the first rules of CI/CD in mind. The first rule is decoupling build system and application property management and the second rule is build once and deploy to multiple servers. One can achieve this by enabling overriding of properties from outside of your generated artifact; you must be thinking, "how the hell can we do it?" Let's say that, in above example, the database URL does not have a hardcoded value pointing to the production server, but has a configurable value reading it from the system variable of the deployment server and we set the database URL value as a system variable on each deployment server, pointing to the relevant database server. For example, for the local machine, we set the value of the database URL as a system variable pointing to the local database, and along similar lines, we set a value on the staging server pointing to the staging database. This strategy decouples the generated artifact from a different deployment server and achieves the two rules mentioned above.

With the introduction of Spring Boot, property management from outside the build artifact has become very easy by supplying an overridden configuration property file path in the run command of your application. There are many different ways we can achieve decoupling of the build system and application property management, but this article is not about how we can overcome this problem in different ways. This article was written to make developers aware, if they have a mindset that CI/CD is only the responsibility of the DevOps team and they have no role to play in the faster rollout of their application to production.

As a developer, these things should be part of your design discussion so that you can enable CI/CD without making application-breaking changes later on. Good, configurable application code is a pillar for achieving Continuous Integration/Deployment, and a developer is the chef of this recipe.

Interested in Kubernetes but unsure where to start? Check out this whitepaper, A Roundup of Managed Kubernetes Platforms from Codeship by Cloudbees, for an overview and comparison of Kubernetes platforms. 

Topics:
devops ,microservices ,ci/cd ,continuous integration ,continuous deployment

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}