Posts

Showing posts with the label Continuous deployment

Continuous Delivery (CD) Getting started - concept to reality

Image

Top 8 principles of Continuous Delivery

Jez Humble and Dave Farley defined the following principles in their Book “Continuous Delivery”: Repeatable reliable process  – use the same release process in all environments. If a feature or enhancement has to work through one process on the way into the integration find a way of popping up. Automate everything  – automate your builds, your testing, your releases, your configuration changes and everything else. Manual processes are inherently less repeatable, more prone to error and less efficient. Once you automate a process, less effort is needed to run it and monitor its progress – and it will ensure you get consistent results. Version control everything  – code, configuration, scripts, databases, documentation. Everything! Having one source of truth – and a reliable one – gives you a stable foundation to build your processes upon. “Bring the pain forward”  – deal with the hard stuff first. Time-consuming or error prone tasks should be dealt with as soon...

Continuous Delivery - An Example

An example of an idealized, modern software delivery pipeline might look like the following:  • Plan user stories and manage issues with a project management tool like JIRA.  • Collaborate on code via GitHub pull requests or a code review tool.  • Kick off a build in a CI system like Jenkins or Bamboo.  • Automatically run unit and functional tests with open source testing tools like xUnit and other testing frameworks, and automation tools like Selenium and Appium.  • Deploy with an IT automation tool like Puppet or Chef, or using a PaaS.  • Monitor performance and impact on business metrics with systems like New Relic and Mixpanel.

Set Up Continuous Integration with Team Foundation Server

Image
TFS infrastucture  For PROD, you may like to have Nightly Builds, for Development you want to have a build triggered at every check-in and so on…  These builds require a build server.  You can use 1 build server for all the builds or you can have a separate build server for each Repository, or you can share build server between 2 repositories. The decision to use one-build server or more depends on the peak-load, expected build queue, h/w infrastructure and a lot of other parameters.  If you do not want build services, you do not need to configure a build server at all. http://www.codetails.com/2013/11/23/team-foundation-server-understanding-the-architecture/   Set Up a Dedicated Build Server Installs the build service on the team's build server Set Up the Drop Folders A folder where the Team Foundation build service can drop the builds. Give the folder permissions to the server that runs the build service Create the Continuous-Integ...

11 common DevOps Bottlenecks

1. Inconsistent Environments Create standard infrastructure blueprints and implement continuous delivery to ensure all environments are identical. 2. Manual Intervention Automate the build and deployment processes and implement a test automation methodology like test driven development (TDD) 3. SDLC Maturity Invest in training and hold blameless post mortems to continously solicit feedback and improve. 4. Legacy Change Management Processes Companies with legacy processes need to look at how they can modernize processes to be more agile instead of being the reason why their company can’t move fast enough. 5. Lack of Operational Maturity Assess your operational processes, tools, and organization and modernize to increase agility and transparency. 6. Outdated testing practices Quality is everyone’s responsibility, not just the QA team. 7. Automating waste Automate processes after the bottlenecks are removed. ...

DevOps in Agile environment

DevOps is the practice of operations and development engineers participating together in the entire service lifecycle, from design through the development process to production support. DevOps is also characterized by operations staff making use many of the same techniques as developers for their systems work. “Ops” is a blanket term for systems engineers, system administrators, operations staff, release engineers, DBAs, network engineers, security professionals, and various other subdisciplines and job titles. “Dev” is used as shorthand for developers in particular, but really in practice it is even wider and means “all the people involved in developing the product,” which can include Product, QA, and other kinds of disciplines. DevOps Practices  –Specific techniques used as part of implementing the above concepts and processes. Continuous integration and continuous deployment, “Give your developers a pager and put them on call,” using configuration manage...