Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
Showing results for 
Search instead for 
Did you mean: 
Quite often when new member joins development team there is a period of adjustment. Libraries, tools, SDKs installations take place chasing not so easy to find common ground for development environment between developers. It can take several weeks until all parts of development environment click together just right on newcomer's laptop or desktop. For ongoing project this means reduced development time, increased costs, lower quality. After a while all is good and newcomer is on the track. But pretty soon some parts of development environment change, new library or tool has come out and again starts tweaking of development environment, only now for all members of development team and in the end question is "Will all team members have development environment in sync?".

In ideal situation developers should just pull code from repository, develop, test, push and merge code back. Ideally developers should not be concerned with Development Environment, it should be delivered to them ready for use and with already established development pipeline they could easily follow. Based on these ideas simple overview of solution can be created:

In order to better understand this solution let's apply it for example to HANA project. We would like to distribute our new CDE to all developers, good way would be to create virtual machine image with CDE and distribute it. Better way would be to distribute script for building CDE image. There are several options how to do that, for example using Docker. Docker files used to build Docker images will allow us to automate almost all aspects of preparing CDE image tailored to each developer. As part of CDE image building process we can script everything we need, download necessary libraries, tools, SDKs, get project related data like usernames, passwords, database schema names and use that to create helper scripts, get repo location on developer's machine etc. In this example resulting CDE image would have:


  • Jenkins configured to run developer tasks (package, build, test, deploy, ...).

  • helper scripts for Jenkins and running CDE tasks like local/remote HCP deployment, etc.

  • mounted local repo clone of remote repository

Our previous simple overview evolved to the following CDE solution:

This enables all developers to share same CDE quick and easy and to be able to independently develop and test new features, deploy and test locally (in CDE) or deploy and test on HCP within their own instance of application and database. There is no risk of changing CDE by developers since resulting CDE image is (almost) read only. CDE can be changed when its needed (e.g. library version change) or as planned and distributed to all developers from single source and all developers will share new CDE in a matter of minutes. Although CDE solution can be used independently, it can also be part of Continuous Integration, Continuous Delivery or Continuous Deployment practices.
Labels in this area