In all the companies I worked as configuration manager I did my best to go with flow. The flow in my case always were the developers. I know that by interfering with the development process nothing can be achieved and it will all backfire at me. So in every job I started I examined the developers work and did what ever I could to improve their most frustrating process first.<\/p>\n
At Zend it was the build<\/a> process using Jenkins<\/a>(see “Job requirements: Laziness<\/a>“) which saved developers time spent waiting the Integration team prepare a build<\/a>. at MusicLab it was the branded full installation build created by CruiseControl<\/a> which improved the branding procedure and allowed using exact same code<\/a> to create different brands in build process. This allowed less fuss for developers and the launches of fixes much faster. At LeumiCard the main issue was deployment<\/a>, the deployment<\/a> was a manual handled procedure which required instruction documents to operators and many different servers. By automating this process the developers had less documents and bureaucracy and I get it done by only a click of a button .<\/p>\n The Main purpose for this quick effort was to convince the developers that the process is worthwhile. Most developers believe that the ALM<\/a> process decrease productivity since, in their eyes, the best procedure is compiling on their PC and coping to production. By proving the benefits of ALM as quickly as possible you can get them on board when you really start adding requests such as code review,work items etc…<\/p>","protected":false},"excerpt":{"rendered":" In all the companies I worked as configuration manager I did my best to go with flow. The flow in my case always were the developers. I know that by<\/p>\n