You are currently viewing Agile DevOps – Case of using Jenkins for multiple sites, implementations, and environments for .NET Cloud Apps (Part-1)

Agile DevOps – Case of using Jenkins for multiple sites, implementations, and environments for .NET Cloud Apps (Part-1)

We faced several challenges working with our existing CI systems, namely Bamboo and TeamCity while setting up our CI/CD pipelines on on-prem private cloud and hybrid cloud infrastructure for our clients. To overcome these challenges we decided to evaluate Jenkins, and to our surprise, everything went seamlessly. It took us some time before we could get the ‘msbuild’ to work. After installing Visual Studio build tools on the build servers, msbuild started working smoothly. In this blog, I’ll try to outline the challenges and steps we followed to get our complete CI/CD environment setup and configured with Jenkins.

Challenges with Jenkins

The cloud base solution we developed for our clients requires tons of configuration to settings and workflows per customers requirements.  The workflow rules are defined in the database and work differently for each implementation, so in necessitated testing with various personas and custom configured environments. Several modules of the solutions, like Administration, Customer Portals, Contractor Portals, and Web services were deployed and used with different configuration and versions by multiple customers. The figure below depicts components deployed on different server environments and logically composed into a complete solution.

Another challenge was to support multiple environments like – DEV/QA, RELEASE, STAGE, and PRODUCTION, with a lot of the configuration stored in the database. The standard config files are kept to bare minimum and contained stuff like connection strings, log configuration, etc. making it easier to build once and deploy on multiple implementations and environments.

Builds on DEV/QA and RELEASE environments were built from different release branched in the GIT repos. Once the builds were tested in RELEASE environment, the code was then promoted to STAGE for the customer to test and then pushed to PRODUCTION.

Explore more details of it in (Part 2)