Build and Release Training by DevOpsConsulting.in

Build and Release Training by DevOpsConsulting.in

DevOpsConsulting is a brainchild of passionate technopreneurs having vast experience in managing, designing and delivering large scale enterprise solutions with prime focus on achieving business goals with high performance systems. We are an IT technologies and consulting firm specialized in DevOps and software practices to improve efficiency and cost effectiveness of an Organization.

We have extensive experience in various verticals like telecom, healthcare, finance, insurance, media etc. Our comprehensive knowledge and expertise includes but not limited to DevOps Architect Design, Technical Debt Reduction, Cloud Migration, Continuous Integration, Continuous Delivery and Continuous Deployment.

The basic course program is outlined here

• Software Configuration Management overview
• Introduction of Version management / Source Code Management
• Overview of Build management
• Overview of Packaging management
• Overview of Release and Deployment management
• Git - A Source Code Management Tool
• SVN - A Source Code Management Tool
• Apache Ant - A Build Tool
• MsBuild - A Build Tool
• Nant - A Build Tool
• Jenkins - A Continous Integration Tool
• RPM - A Linux Package Management
• Jboss - A Application Server
• Bash Scripting - A Scripting Language
• Linux and Windows - Operting System
• Overview of Continuous Integration
• Overview of Continuous Delivery
• CI/CD Implementation

More - http://www.devopsconsulting.in/build-release-training.html

Email at - info@DevOpsConsulting.in

DOT NET Build and Release Training at Microsoft platform Using Teamcity & Jenkins

DOT NET Build and Release Training at Microsoft platform Using Teamcity & Jenkins This Training is specially designed for the engineer who wants to excel their career in Build and Release and DevOps domain using Microsoft Platform in DO NET. We are using tools like TeamCity and Jenkins for CIs, apart from MsBuild, NAnt, Octopus, Nuget and Chef using DSC.

Click Here

Course Outline :

Concept / Process / Principals / Overview

• Software Configuration Management overview
• Elements of Software Configuration Management
• Introduction of Version management / Source Code Management
• Overview of Build management
• Overview of Packaging management
• Overview of Release and Deployment management

Source Code Management Tools

• Git - Source Code Management
• Team Foundation Server (TFS)

Build Tools

• NAnt - A .NET Build Tool
• Msbuild - A dot net based build tool

Continuous Integration Tools

• Teamcity - A continous integration tools
• Jenkins - A continuous integration tool

Application Packaging Management Tools

• Nuget - A windows based application packaging and management tool

Deployment Management / Configuration management - Fundamental only

• Octopus - Smarter Deployments in Windows
• Chef in Microsoft Windows using Desired State Configuration (DSC)

Web server - Fundamental only

• Internet Information Services (IIS) 7.0

Operating SystemÂ

• Windows - A Microsoft operating system

Scripting

• PowerShell - A task automation and configuration management framework from Microsoft

CI/CD Concept and Implementation

• Concept of Continuous Integration
• Concept of Continuous Deployment
• Concept of Continuous Delivery
• CI/CD Implementation

What is the future of Build and Release Engineer? Part-2

To continue from my part 1, next answer is given by Stephan Schwab. He is International Software Technology and Agile Development Consultant. Thanks much for such a realistic views on Build/Release Engineering. I personally don't agree with Stephen's views but as a free blogger, it is my responsibilities to present facts as it is.

He says- I'm creating software since 1981 and have never felt any need for a dedicated build/release engineer. Regardless of the language used.

Don't confuse build/release with deployment/operations. For the latter you certainly want to have a dedicated team to fulfill these functions.

In agile development you should have an automated build that never - under no circumstances - takes more than 10 minutes to finish and doesn't depend on any infrastructure. So "building" is just a matter of checking out the code from the repository on a virgin machine and then you start the build. If you have to setup the environment, install a database or whatever else, then you are asking for trouble. Don't do this.

I've seen build/release engineers at clients who were just acting as a roadblock to developers. These guys usually make things complicated just to protect their job. That's not in the interest of the development team neither of the company they work for.

A good build is simple, requires no maintenance and everybody on the team is responsible to execute it multiple times a day to run all the tests before submitting new code. And developers should not sit on code either but integrate frequently and early.

Build and Release Definitions

These are the basic definitions every Build and Release Engineer should be aware of. Build and Release, these two terms are so related to each other that sometime they are used interchangeably. To minimize the confusion, I compiled these definitions.

Build and Build Management- The process of converting source code artifacts into some desired product executable file. Historically, this is thought of as "compiling," but it also includes things like linking, packaging. The control of the "source of the source", the build environment, build scripts and build schedules. The person who "manages" the build environment and controls execution of builds is called a Build Manager, even though they rarely have any management responsibilities. While in larger organizations there may well be a Manager of the Build Team, this is not what is meant by the term Build Manager. Think of Build Management as being in control of the kitchen, the equipment within it and the available ingredients, as well as cooking pies. In this analogy, a Build Manager is the head chef.

Release and Release Management- A release is the consolidation of all deliverable elements, whether resulting from a build, generated artifacts from another process or acquired from third parties, into a controlled staging area. It is generally organized into the same package(s) so that it can be deployed to customers or end users. A good release is the one which contains all the deliverables, control information and release notes in one package so the end customer need not to worry much about deployment. One can think of a release as a shrink-wrapped package full of "good stuff." Continuing the analogy, a release is a pie in a box with the appropriate labels affixed. The control of the selection of release components, the release environment and the tool-chain required to produce a release. Note that the description is very similar to that of Build Management. That is because these two activities are closely related. Release Management is analogous to a production line where many pies are produced, boxed, labeled and placed in a storage facility awaiting purchase or shipment.

Build management is the definition, support, and enforcement of processes for preparing software executables from source code (deployment) whereas Release Management is the same thing from deployment to production. Summarily Build is a process whereas Release is an artifacts.

What is the future of Build and Release Engineer? Part-1

Since the time, I have taken the responsibility of Build and Release Engineer in my organization, this is the question spiked up in my mind.
I was, in fact I am very much curious to know the answer. So I asked this questions to many people in the industry through a professional business network contacts. I received the answers to my email but for benefit of other people in the same kind of job, I will be posting those experts' views here.

I am starting with the answer of Mr. Phil Davidson, Senior Program Manager at Microsoft. I am very much obliged to him for his time to write me this.

He says- I believe it is an area that will still require people and focus, however, I believe that the mindset and activities will transform. With the current pace and change to be "agile", it becomes more important that there is a process that can allow the developers to keep focused on building products and features instead of needing to worry about setting build systems and servers.
The world of Build will need to start focusing on providing a service to the development teams and in that provide the necessary systems and support to ensure that the dev teams can deliver high quality code.
By ensuring the proper quality gates are incorporated as a part of the build or post build process ensures that once the code is checked in, you know it is in as good if not better state than it was prior to the check in.

I believe that part of the responsibility will be in the area of consulting where they can provide the dev teams with recommendations and guidance. The build service team can help them to be able to know the best ways to utilize the service and system to get the biggest bang for their buck. The release team will be able to help them in regards to deploying or shipping the highest quality products and services through making sure the right processes, procedures, and quality gates are in place or get setup.

Another area is in the area of tools. Tools that will automate and facilitate and ensure that devs can be running at as fast a speed as possible without reducing the quality nor the stability of the product/services they provide. This is really about ensuring the ability to scale up and scale out as we watch the speed of software development as well as the size and number of products continue to grow.

I believe there is a need going forward, it is up to the build and release people to make sure that it adapts to the changes being seen and adopted by the development teams around the world. The skills of how to build and ship/deploy a product in the best way to optimize the build and release experiences.