Anexinet was recently asked to define a DevOps pilot workshop to assist an organization in understanding what an end-to-end solution could look like.
One challenge with defining a DevOps workshop surrounds providing a meaningful deliverable. There is no true “definition” of DevOps as it is a philosophy or vision of the best practices. However, in order to demonstrate a working vision, a deliverable needs to be defined. The rest of this article discusses this deliverable.
To define this deliverable, the following questions needed to be asked:
- What are the goals?
- What application will be delivered?
- Which tools should be deployed?
- What environment(s) are needed?
There was not one answer to this challenge. The decision was made to use a set of free/open source/trial tools that have a predominant footprint within their respective DevOps functional areas.
The goal of the workshop is to deploy an application to a public cloud demonstrating the concepts of Continuous Integration and Continuous Delivery. More specifically, upon a commitment of a change to the source code by a programmer to the source control repository, have the build server automatically build the code, execute tests and, upon successful test execution, deploy the application to a publicly accessible Azure App website.
The following tools were chosen for this workshop:
- Source Control: Subversion (SVN) using VisualSVN Server
- Continuous Integration: TeamCity
- Continuous Delivery: Octopus Deploy
- DevOps VM environment: Azure Infrastructure as a Service (IaaS)
- Application Deployment Environment: Azure App Services
To meet the goal of the workshop, something needs to be defined and built for deployment. In this workshop, a REST API service was built with Microsoft Visual Studio’s Web API project template as the application. A simple REST API endpoint can be setup fairly quickly and can be hosted within Azure’s App Service. Furthermore, the REST API provides a project to compile as well as write unit tests for. Any application that can be built, tested and hosted by Azure’s App Service would suffice (ex: An MVC or ASP.NET web application).
In the rest of this article, the steps in the workshop will be introduced. Steps include:
- Setting up DevOps Tools
- Application Creation
- Configuring the Build Server
- Configuring the Deployment Server
- End to End Test
Note: During the actual workshop, a lot more specifics on each step were presented and discussed. When walking through the list of steps, we learned that even the simplest DevOps implementation somehow becomes not so simple. The challenges of orchestrating the number of needed tools together calls on a wide range of system engineering (and internet search) skills. If there is one takeaway from reviewing the below steps, it is that there needs to be pre-planning before venturing into the DevOps world. Business objectives, time frames, tool selection, team responsibilities and personnel skill sets are just a few items that need to be defined up front.
Workshop Step Highlights
Environment Set Up
Before the chosen DevOps solution can be built out, the selected DevOps tools that will be used in the workshop must be installed. There are many choices when it comes to where to install the selected tools (self-hosted, private cloud, Software as a Service [SaaS]). For the purposes of this workshop and to keep the networking simple, the set of DevOps tools was installed on a single Azure Virtual Machine (VM), which used their Infrastructure as a Service (IaaS) offering. Note that in a typical installation these tools would be deployed to different machines for security and load/capacity/scaling reasons.
Azure Account Set Up
In order to create a Virtual Machine in Azure, a subscription needs to be created. A free subscription can be utilized for this workshop.
Azure subscriptions are consumption based. This means that when resources are consumed, there are billing implications. For example, when Virtual Machines are running, charges accrue for both the disk allocation as well as compute time. When Virtual Machines are powered off and de-allocated, then the compute resources are freed up and the account is only charged for the disk consumed. When utilizing the credits of a free subscription, it is beneficial to power down and de-allocate virtual machines when not in use. When “non-free” subscriptions are used, there are also cost saving benefits to de-allocating resources when not needed (for example a QA environment is likely not necessary 24/7).
Azure Virtual Machine (VM) Set Up
As discussed above, a server is needed to host the chosen DevOps tools for the workshop. This workshop utilized one virtual machine defined using the Standard A2 server template.
Costs can be controlled by de-allocating resources when not in use. This workshop covered; defining PowerShell commands to log in to Azure, and start and stop the defined VM. The Azure portal could be used instead of PowerShell to interactively manage the VM once created. However, utilizing PowerShell exposes some of the scripting capabilities of Azure resources.
Source Control Application Set Up
The following tasks are covered in the workshop for installing the source control server:
- Install VisualSVN Server on the Azure created VM
- Set up a repository for the application source code.
- Open up a port in the Azure Network Security Group and the Virtual Machine’s firewall to allow remote access to SVN and support source code check in from the developer’s local machine.
Continuous Integration (CI) Application Set Up
The following tasks are covered in the workshop for installing the build server:
- Install TeamCity on the Azure VM.
- Install SQL Server Express (including SQL Server Management Studio) for TeamCity to use to store its configuration.
- Enable TeamCity as a NuGet Package feed.
- Add the Octopus Deploy component into TeamCity.
- Optionally, to manage TeamCity from a local browser, open up the appropriate port in the VM Firewall and the Azure Network Security Group.
Continuous Delivery (CD) Application Set Up
The following tasks are covered in the workshop for installing the Delivery/Deployment server:
- Install Octopus Deploy Server. With this solution, an Octopus Deploy Tentacle will not be used as it is not needed for deployment to the Azure App Service.
- Optionally, to manage Octopus Deploy from a local browser, open up the appropriate port in the VM Firewall and the Azure Network Security Group.
An Azure Web App needs to be created to host the REST API application.
Application Creation / Source Controlled
Utilizing Microsoft Visual Studio Community Edition a simple REST API service will be built on the developer’s machine. A REST API is chosen as it is a relevant application component in today’s development circles. In addition to building out the API, a unit test project will be added. This project will contain a set of unit tests which will be executed by the CI server on code build.
To allow for the developer to interoperate with the source control server, TortoiseSVN will be installed on the developer’s machine. This provides File Explorer shell integration to connect with SVN servers. Additionally, for Visual Studio integration, the AnkhSvn plugin can be installed in Visual Studio. Once the application is written, the solution will be checked into the SVN server.
Configuring the TeamCity Build
In this step the TeamCity project and build configuration is set up. This project will perform the following steps:
- Monitor SVN for source code check ins
- Upon check in, build the application
- On successful compilation, execute the unit tests
- On successful unit test execution, communicate with Octopus Deploy to start code deployment
Configuring Octopus Deploy deployment process
In this step Octopus Deploy environment is set up. This environment will be set up to do the following:
- Set up a certificate to allow Octopus Deploy to connect to your Azure App Service
- Set up Octopus Deploy to have access to the TeamCity NuGet feed
- Upon triggering by TeamCity, create a release and deploy the application to the Azure App Service
End to End Test
Targeted testing will take place to ensure that each piece is functioning properly. The final test is to see this working from end to end. To test this, the source code should be modified on the developer’s machine and this change should be checked into SVN. In the workshop, we will change the dataset that is returned from a REST GET endpoint. Upon check in to SVN this will trigger the CI and CD processes. A quick test to that website hosted in Azure will indicate if the code change was deployed successfully. Additionally, the workshop will show the ‘fail fast’ principles of DevOps in that:
- If a non-compiling change is checked in, the TeamCity build will fail, provide feedback and not continue in running the unit tests.
- If a unit test fails, the TeamCity build configuration will fail, provide feedback and not continue on to trigger the Octopus Deploy release.
- If an Octopus Deploy release fails to deploy, the build configuration fails and provides feedback.
Even the most simple of DevOps solutions can get complicated very quickly. In this workshop, numerous tools and products were integrated together to solve our Continuous Integration and Delivery goal. Taking this type of workshop and expanding on it to meet a corporation’s business goals will help start your DevOps vision. Additional DevOps topics to understand that are not covered in the workshop include, but are not limited to:
- Infrastructure as code environment set up
- Orchestrating deployments through multiple environments
- Managing system configuration parameters through different environments
- Automated application testing on deployment with automatic promotion on success
- Leveraging a micro services architecture to take full advantage of Continuous Deployment
Anexinet is a leading professional consulting and services company, providing a broad range of services and solutions around digital disruption, analytics (and big data), and hybrid and private cloud strategies. Anexinet brings insight into how technology will impact how business decisions will be made and how our clients interact with their customers in the future.
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
|cookielawinfo-checbox-analytics||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".|
|cookielawinfo-checbox-functional||11 months||The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".|
|cookielawinfo-checbox-others||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.|
|cookielawinfo-checkbox-necessary||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".|
|cookielawinfo-checkbox-performance||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".|
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
Other uncategorized cookies are those that are being analyzed and have not been classified into a category as yet.