We’ve all done it.  There’s no need to be ashamed.  Heck!  I even have a ritual around it.  I shut my office door.  I close the blinds.  I play soothing music and just about when Elton John belts out, "Blue jean baby!"…wait, that’s not what I meant (get your minds out of the gutter).  I use this relaxing setting to check Glassdoor and see what is being said about my organization.  Like you I dread the scathing review of HR and how we literally handle our business.  Don’t get me wrong.  I am not too concerned about the reviews...

By Suzanne Miller Principal ResearcherSoftware Solutions Division This blog post is the sixth in a series on Agile adoption in regulated settings, such as the Department of Defense, Internal Revenue Service, and Food and Drug Administration. "Across the government, we’ve decreased the time it takes across our high-impact investments to deliver functionality by 20 days over the past year alone. That is a big indicator that agencies across the board are adopting agile or agile-like practices," Lisa Schlosser, acting federal chief information officer, said in a November 2014 interview with Federal News Radio. Schlosser based her remarks on data collected by the Office of Management and Budget (OMB) over the last year. In 2010, the OMB issued guidance calling on federal agencies to employ "shorter delivery time frames, an approach consistent with Agile" when developing or acquiring IT. As evidenced by the OMB data, Agile practices can help federal agencies and other organizations design and acquire software more effectively, but they need to understand the risks involved when contemplating the use of Agile. This ongoing series on Readiness & Fit Analysis (RFA) focuses on helping federal agencies and other organizations in regulated settings understand the risks involved when contemplating or embarking on a new approach to developing or acquiring software. Specifically, this blog post, the sixth in a series, explores issues related to system attributes organizations should consider when adopting Agile. A Framework for Determining Agile Readiness Many organizations, especially in the federal government, have traditionally utilized a waterfall lifecycle model (as epitomized by the engineering "V" charts) for software development. Programming teams in these organizations are accustomed to being managed via a series of document-centric technical reviews, such as design reviews. These reviews focus on the evolution of artifacts that describe the requirements and design of a system rather than its evolving implementation, as is more common with Agile methods. Because of this significant difference in focus, many organizations struggle to adopt Agile practices and find it hard to prepare for technical reviews that don’t account for both implementation artifacts and the availability of requirements and/or design artifacts that are at different levels of abstraction. On the other hand, some organizations are surprised to discover they are already performing some of the practices of Agile methods, which can ease Agile adoption. The method for using RFA and the profile that supports CMMI for Development adoption are found in Chapter 12 of CMMI Survival Guide: Just Enough Process Improvement. Adopting new practices like those found in CMMI models involves adoption risk, as does the adoption of many other technologies. I first used RFA in the 1990s to identify adoption risks for software process tools. Since that time, I have used RFA to profile various technologies, including CMMI and, now, Agile. For the past several years, the SEI has researched adoption of Agile methods in U.S. Department of Defense (DoD) and other government settings. SEI researchers have adapted the RFA profiling technique to include typical factors related to adopting Agile methods for any setting. We have also focused on other factors more uniquely associated with adopting Agile methods in highly regulated government acquisition environments, such as the DoD and Department of Homeland Security. To date in this series, we have characterized four of the six categories to profile for readiness and fit: business and acquisition (discussed in the first post) organizational climate (discussed in the second post and continued in the third post) project and customer environment (discussed in the fourth post) practices (discussed in the fifth post) system attributes (discussed in this post) technology environment (will be discussed in the next post) Categories and factors continue to evolve as we pilot the analysis in client settings, but these six listed above are the ones we are currently using. Applying the Readiness & Fit Analysis Each category of readiness and fit has a set of attributes that can be characterized by a statement representing the expected behavior of a successful Agile project or organization operating in relation to that attribute. For example, an attribute from the system attributes/technology category is stated as follows:Loosely-coupled architecture. Product architecture allows for at least some of the components to be produced independently (architecture reflects loose coupling). Application Notes: At the beginning of an Agile adoption project, organizations are often uncertain about their current state in terms of adoption factors or the importance of individual factors (such as alignment of oversight practices with Agile practices) to organizational adoption success. Later in the process, an RFA can highlight adoption risk areas that were overlooked during earlier phases of adoption. Using the example above, an organization may have an architecture already in place when it considers adopting Agile practices that is not loosely-coupled and contains many dependencies. This will make it harder to create independent slices of functionality. There will be inherent rework because of architectural dependencies as the system evolves.  After one or two pilots, however, the impacts of the tightly coupled architecture may motivate a strategic pause to explicitly rework the architecture to more readily accommodate incremental, iterative Agile approaches.  After that re-architecting, this would no longer be an area of adoption risk, and the organization can move on to dealing with other issues. The key point here is to be prepared to apply RFA principles and techniques at multiple points in your adoption journey. The remainder of this post is dedicated to the System Attributes category. The System Attributes Category System attributes cover technical aspects of the product under development and determine whether work benefits from division into smaller chunks that can be produced iteratively and built upon over time. If the program cannot be broken into loosely coupled, smaller chunks, then it will be hard, if not impossible, to produce "slices" of functionality that can stand alone and provide usable functionality at the end of each iteration. Each iteration in an Agile development effort ideally produces potentially shippable code (not always to external customers, it could be for internal customers). This production of usable functionality frequently means that someone could deploy and use the code to achieve some tangible benefit prior to the entire product’s completion. As in other RFA categories, the following list has both a tag (a short title that summarizes the statement) and a statement that provides a condition or behavior one would expect to find in an organization with successful engineering and management methods consistent with Agile principles, as published in the Agile Manifesto. Loosely-coupled architecture. Product architecture allows for at least some of the components to be produced independently (architecture reflects loose coupling). From an Agile perspective, a loosely-coupled architecture has two implications. First, in an Agile environment, each iteration should yield potentially shippable code. With a loosely-coupled architecture, a component can be produced independently, and it should be easier to produce something usable within one iteration. Second, in today’s environment, especially for large DoD programs, the staff is distributed across multiple locations. While modern communications supports the use of Agile methods in these distributed environments, it is easier for one team to be responsible for an independent module with loose coupling than for a module with many interfaces requiring significant communication and collaboration. System supports iterative delivery. System or service type is compatible with an incremental release and delivery strategy. The third Agile principle states, "Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale." If the strategy for the system or service type is based on a strategy that requires a plan-driven, documentation-centric approach—complete with multiple milestones, large reviews, and "big bang" integration—then the shorter iterative approach will be incompatible and potentially cause additional work and many disconnects throughout the development. Critical dependencies accounted for. Mission and safety-critical components and dependencies are identified and accounted for in the program strategy. Agile programs deliver working software frequently. If mission and safety-critical components and dependencies are not identified and accounted for in the program strategy, however, the software could easily be incomplete and cause significant rework. In fact, the ninth Agile principle states, "Continuous attention to technical excellence and good design enhances agility."  This principle means that the critical components and dependencies should be considered up front. This principle also relates to the importance of paying close attention to architecturally-significant requirements as part of the early activities. Some programs deal with this in a "Sprint Zero" before the actual software development begins. Others use the concept of an architectural runway to ensure that dependencies and interfaces are understood to a useful level before implementation decisions are made. Security requirements accounted for. Security drivers are accounted for in the program strategy. As with critical dependencies, continuous attention to technical excellence and good design requires the developers to consider security requirements up front and throughout development. This consideration is particularly true with DoD or other complex programs (also found in healthcare, medical devices, and financial systems, to name a few) that have complex security requirements. Failure cost accounted for. Cost of failure is understood and accounted for. Failure can take on many forms—working software that does not deliver the needed functionality, late software deliveries, or software development that is incompatible with the rest of the organization. The 12 Agile principles counter these issues. However, the organization must take into account Agile development activities with relationship to the overall project and to the organization’s culture. If these relationships are not in sync, the overall Agile project could be in jeopardy. Appropriate criticality. Criticality of the software in meeting business or mission goals is addressed for the program. Many teams embrace Agile methods because the software is needed quickly or provides a competitive advantage. If the criticality attribute of the requirements is not prioritized appropriately, however, even software delivered early and often may not provide the required functionality. Sound engineering principles are still required when employing Agile methods, as emphasized in the first part of the ninth Agile principle "Continuous attention to technical excellence…" The system attributes category may be smaller in terms of the number of attributes addressed, but is an important area for successful Agile adoption. The next post in the series will present the final category in this series on RFA, technology environment, and complete our whirlwind tour of the six categories in the Agile Adoption in DoD RFA model. I look forward to hearing your experiences adopting Agile methods, especially those operating in regulated environments. Please leave a comment below or send an email to info@sei.cmu.edu. Additional Resources The SEI technical note, Agile Methods: Selected DoD Management and Acquisition Concerns, outlines many of the project and customer environment issues that arise in Agile adoption in the DoD. To download the report, please visithttp://www.sei.cmu.edu/library/abstracts/reports/11tn002.cfm. Some of the issues related to project and customer environment challenges are also detailed in the October 2013 SEI technical note, Parallel Worlds: Agile and Waterfall Differences and Similarities, which can be downloaded athttp://resources.sei.cmu.edu/library/asset-view.cfm?assetID=62901. I am recording a series of podcasts with Mary Ann Lapham exploring the real-world application of Agile principles in the DoD. To view the series or download episodes, please visithttp://www.sei.cmu.edu/podcasts/agile-in-the-dod.

By Joe YankelMember of the Technical StaffCERT Cyber Security Solutions Directorate This post is the latest installment in a series aimed at helping organizations adopt DevOps. Docker is quite the buzz in the DevOps community these days, and for good reason. Docker containers provide the tools to develop and deploy software applications in a controlled, isolated, flexible, highly portable infrastructure.  Docker  offers substantial benefits to scalability, resource efficiency, and resiliency, as we’ll demonstrate in this posting and upcoming postings in the DevOps blog. Linux container technology (LXC), which provides the foundation that Docker is built upon, is not a new idea. LXC has been in the linux kernel since version 2.6.24, when Control Groups (or cgroups) were officially integrated. Cgroups were actually being used by Google as early as 2006, since Google has always been looking for ways to isolate resources running on shared hardware. In fact, Google acknowledges firing up over 2 billion containers a week and has released its own version of LXC containers called lmctfy, or "Let Me Contain That For You." Unfortunately, none of this technology has been easy to adopt until Docker came along and simplified container technology, making it easier to utilize. Before Docker, developers had a hard time accessing, implementing, or even understanding LXC let alone its advantages over hypervisors. DotCloud founder and current Docker chief technology officer Solomon Hykes was on to something really big when he began the Docker project and released it to the world as open source in March 2013. Docker's ease of use is due to its high-level API and documentation, which enabled the DevOps community to dive in full force and create tutorials, official containerized applications, and many additional technologies. By lowering the barrier to entry for container technology, Docker has changed the way developers share, test, and deploy applications. How can Docker help us in DevOps? Well, developers can now package up all the runtimes and libraries necessary to develop, test, and execute an application in an efficient, standardized way and be assured that it will deploy successfully in any environment that supports Docker.  Initial reactions to container technology often compare containers to small virtual machines. However, the advantages of containers over VMs becomes apparent with regards to performance.  In particular, a Dockerized application starts quickly, without the need to perform all of the steps associated with starting a full operating system. These containers share the operating system kernel, and other binaries and libraries where appropriate. Below is an image from the Docker website that highlights the differences. In particular, note how containers incur much less time and space overhead than virtual machines. Docker vs Virtual Machine Another great feature is the built-in versioning that Docker provides. This "git-like" versioning system can track changes made to a container, and both public and private repositories (if your organization desires or requires) can be used to store the versioned containers. Docker had a big impact in 2014, and in 2015 you can expect even greater adoption by both small and large companies. This uptake is evident since Docker support has quickly been adopted by major cloud services, such as Amazon Web Services and Microsoft Azure. We expect Docker to play a key role in future conversations that focus on designing, building, and deploying applications, especially with the guarantee that an application will run in a production, or customer environment, just as it did during development and testing. A few weaknesses become evident when it comes to communication between Docker containers running on different servers, but this will only improve with time. You can also expect some competition around the corner in 2015. If you haven't tried Docker yet, definitely give it a try. This technology is really just beginning to fire on all cylinders and so much more is to come. Every two weeks, the SEI will publish a new blog post that will offer guidelines and practical advice to organizations seeking to adopt DevOps in practice. We welcome your feedback on this series, as well as suggestions for future content. Please leave feedback in the comments section below. Additional Resources To listen to the podcast, DevOps—Transform Development and Operations for Fast, Secure Deployments, featuring Gene Kim and Julia Allen, please visit http://url.sei.cmu.edu/js. To read all the installments in our weekly DevOps series, please click here. Published in the series thus far:  An Introduction to DevOps A Generalized Model for Automated DevOps A New Weekly Blog Series to Help Organizations Adopt & Implement DevOps DevOps Enhances Software Quality DevOps and Agile What is DevOps? Security in Continuous Integration DevOps Technologies: Vagrant DevOps and Your Organization: Where to Begin  

The month of May has always been my favorite month of the year. I was born and raised in Speedway, Indiana, and if you don't know about this small town, it is famous for the Indianapolis 500. The Indianapolis Motor Speedway is the lifeblood of the town and community and it will always hold a special place in my heart. The month also brings some of my greatest heartaches. I lost a dear friend, in 2013, on race day. We attended the race together in 2012 as this was a "bucket...

Our vision for DWP is to put user needs at the heart of our thinking, delivering the policy intent through digital services which we continuously improve. We recognise there is an opportunity for us to deliver some of our services in a much more modern and efficient way, by collecting and using data in a more joined-up way, automating whenever it’s safe to do so, constantly improving our services and reacting rapidly to user feedback. We’re working on DWP’s Business Design to help communicate and join-up all of our change efforts across the organisation. The six Enablers in DWP’s Business Design   To summarise our more detailed work, we’re highlighting six critical ‘Enablers’ of our transformation journey. We are integrating these throughout our design, so that they become part of the fabric of how we do things at DWP: Secure self-service wherever possible - our ability to create simple, secure and responsive online services. These need to be so good and so trusted that our customers choose to use them whenever they can in preference to other channels. Decision-making based on trust and risk - our ability to understand the trust level and risk associated with each individual transaction we process, so that we can spot patterns and intervene when we need to. Risks could be risk to a customer (e.g. due to their health condition) or to government (e.g. fraud). Intelligent data use, sharing and management - our ability to use data to drive more efficient services. Integrating and sharing data within DWP and beyond, supported by the right technology and data science skills. Advanced analytics for segmentation - our ability to identify customers who may be vulnerable or require a different level of service, so that we can offer appropriate customer journeys and provide better decision-making support to our front-line staff. Automated processes - our ability to automate processes whenever possible, enabling our people to spend more of their time helping customers. The ability to continuously monitor the performance of our processes and improve them. Customer behaviour change - our ability to design and manage our services through continuous improvement to promote customer behaviours and improve social outcomes. Through our current change work, we’re building some aspects of these already. These aren’t just technology enablers. Each of them is the ability for DWP to meet business needs, so it’s made up of people with the appropriate skills and experience, the processes they follow, and the technology that supports the business outcomes. Importantly, they’re not a set-in-stone prescription, but a sketch that will evolve through iteration and learning. We can’t know everything in advance about how the Enablers will work, but we do know that they are all areas where we must have a step-change from today, if we are to realise our vision. The Enablers are not the only things that we need to build, but they are critical ones. This aspect of the design intentionally focuses on the "mechanistic" aspects of the Enablers, and we are working on this hand-in-hand with colleagues focussed on DWP’s culture and behaviours. That means thinking beyond just skills and experience, to consider our attitudes and confidence to challenge current ways of thinking. Our Enablers are the result of work across our community. We’ve agreed them by working across a wide group of people from all over the organisation, and we’ll continue the discussion further in the coming weeks and months. Keep in touch by following Andrew @abesford on Twitter.

Jon Townsend, Head of DWP Cyber Intelligence Response Centre (D-CIRC) We’re boosting our digital capability in our Cyber Intelligence Response Centre (D-CIRC), to ensure we have intelligence-led cyber security for our online services to operate effectively and safely. We’re working with Government and private sector partners to build and mature our capability, detect malicious behavior, and respond to cyber threats. DWP delivers public services that millions of people rely on, which can transform lives. People increasingly expect to access services digitally at a time which suits them, and it is only right that we transform the way we operate to design automated, agile, efficient services, putting customers’ needs first. As we take a more digital delivery approach, we know that cyber-resilience is important to ensure the continuity of our digital services. And we know that an intelligence-led approach works best. This means that we use data from multiple internal and open source feeds to analyse and explain the threat landscape. With this picture of the cyber security threats, we can reduce risks, detect malicious behaviour and recommend appropriate response strategies. That’s why we’re growing digital and technology skills in DWP. Our Digital Academy has trained more than 1000 of our own staff, and academy graduates have gone on to work in teams that are driving the development of digital services. We’re also building our capability, to bring in the skills and experience we need. The market is competitive but we can give people the variety and flexibility they often look for in their digital careers, while giving us the expertise we’re looking for. Our Cyber-Intelligence Response Centre currently has vacancies for a Cyber Intelligence Fusion Specialist and Data Insight Specialists, across a range of grades and levels of experience. Find out more about these vacancies.

There is a dynamic tension in today’s workplace. With the rise of activist investors, the ubiquity of technology that spreads news instantly, and increasing public scrutiny of corporate actions, business leaders are more driven than ever to aim for perfection. And yet the speed of business also forces these leaders to make immediate decisions. So, while there is often a need to make an ideal choice, there is also a need to make a choice now, even if it isn’t perfect. What to do? This is the tension between maximizing and satisficing....

By Joe YankelMember of the Technical StaffCERT Cyber Security Solutions Directorate This post is the latest installment in a series aimed at helping organizations adopt DevOps. In our last post, DevOps and Docker, I introduced Docker as a tool to develop and deploy software applications in a controlled, isolated, flexible, and highly portable infrastructure. In this post, I am going to show you how easy it is to get started with Docker. I will dive in and demonstrate how to use Docker containers in a common software development environment by launching a database container (MongoDB), a web service container (a Python Bottle app), and configuring them to communicate forming a functional multi-container application. If you haven’t learned the basics of Docker yet, you should go ahead and try out their official tutorial here before continuing. To get started, you need to have a virtual machine or other host that is compatible with Docker. Follow the instructions below to create the source files necessary for the demo. For convenience, download all source files from our github repository and skip to the demo section. Our source contains a Vagrant configuration file that allows you to run the demo in an environment that will work. See our introductory post about Vagrant here. If you would rather follow along and create all the files manually, continue with the following detailed steps. Detailed Steps to Create Both Containers 1. Create a directory for our web service application called myapp. In this directory create the following files: requirements.txt Dockerfile webservice.py 2. In requirements.txt, add the following lines to indicate which Python packages will be installed when Docker initializes the container: bottle pymongo 3. In Dockerfile, add the following contents: FROM python:3-onbuild CMD [ "python", "./webservice.py" ] The FROM line tells Docker to pull a specific image from the Docker repository. In this case we get an official Python 3 image. The CMD line provides the command that Docker will execute when the container starts. In this case it runs the Python web application, which we define below. 4. In webservice.py, add the following contents: #!/usr/bin/python from bottle import route, run, debug, default_app, response import os import random from pymongo import MongoClient # Configure DB params db_name = 'slsdb' # Configuration optional default development database host default_host = 'some-development-mongo-host' db_host = os.environ.get('MONGO_PORT_27017_TCP_ADDR', default_host) @route('/') def index(): """ Default landing page. We'll initialize some MongoDB test data here. """ client = MongoClient(db_host) db = client[db_name] r = lambda: random.randint(0,255) color = ('#%02X%02X%02X' % (r(),r(),r())) db.colors.insert({"color":color}) return """ <p>Hello. Creating some default data everytime the page is visited.</p> <a href="http://localhost:8000/hello">See the data!</a> """ @route('/hello') def hello_world(): """ Return the contents of the collection we created at index. """ client = MongoClient(db_host) db = client[db_name] blocks = '' colors = [doc['color'] for doc in db.colors.find()] for color in colors: blocks += '<div style="width:75px; height:75px; border:1px solid;' blocks += 'float:left; margin:1px; background-color:' + color blocks += '">' + color + '</div>' # Add a back link blocks += '<div style="clear:both"><a href="http://localhost:8000">Go back.</a></div>' return blocks app = default_app() debug(True) run(host='0.0.0.0', port=8000, reloader=True) This simple Python web service will insert some color data into the database when we browse to the root URL and deliver the data we inserted when visiting the /hello route. The important thing to take away from this example is how to connect to MongoDB using an environment variable created by Docker to derive the IP address of the MongoDB container. Docker automatically creates a number of environment variables for each container when linking to it in the format of: <name>_PORT_<port>_<protocol> For more details on environment variables, see the documentation. The environment variable that we are interested in is the IP address of the MongoDB container. The IP address can change each time the container is started, so use the environment variable named MONGO_PORT_27017_TCP_ADDR from our application to connect to it. In the webservice.py file, on line 12 we set the variable db_host equal to this environment variable’s value. db_host = os.environ.get('MONGO_PORT_27017_TCP_ADDR', default_host) Now that we have all the files prepared, we’ll start the MongoDB container, build the web service container, and then run it linking both together. Demo Begin by starting in the myapp directory created earlier on the virtual machine. The rest of the tutorial will assume that you are using the Vagrant-generated virtual machine provided with the source code. If you did not use the Vagrant-generated machine, you will need to change any path below matching "/vagrant/myapp" with the full path to your equivalent myapp directory. cd /vagrant/myapp 1. Run the MongoDB container, using the official MongoDB Docker image. This will take a moment to pull the necessary layers from the repository. $ docker run --name mongo -d mongo The Docker run command starts a container. In this instance we are starting a container named mongo (--name mongo). You can name a container whatever you want. The -d indicates to start the container in daemonized mode, or as a background process. Finally, the second mongo is the name of the image to run. If the image is not located locally it will attempt to pull an image named mongo from the Docker repository. To make sure the MongoDB container is running, you can view the running docker containers by executing the docker ps command. $ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES c1fc1ef13e1d mongo:latest "/entrypoint.sh mongod 5 seconds ago Up 5 seconds 27017/tcp mongo 2. Build the Python web service container. Include the trailing '.' $ docker build -t webservice . This command creates a Docker container named webservice based on the Dockerfile in the current directory. 3. Run the web service container and link it to the running MongoDB container. Expose port 8000 and make it available to the host. Notice that we also want to mount the local source code, so we can make code changes on the fly. Use the full path of your myapp directory. $ docker run --name webservice -p 8000:8000 -v /vagrant/myapp:/usr/src/app --link mongo:mongo -d webservice 4. Browse to http://localhost:8000/ to initialize our data. 5. Browse to http:/localhost:8000/hello or use the link on the web app home page to see the data pulled from our MongoDB container. That is all there is to linking containers and using the environment variables that are exposed to connect the containers together in an application. What if you want to actually get on the MongoDB console and see what is in your database? The Docker way of doing this is to start up another Docker container based off the existing MongoDB container and connect to your running instance. There is no need to install the MongoDB client or shell tools on your own host or even guest OS. The official MongoDB image we are using already has these tools, so we just need to start a new container and override its entrypoint. The only thing we need to know is the current IP address of the running MongoDB container. To get this address we inspect the container: $ docker inspect mongo Near the bottom of the output we are looking for the IPAddress value in the NetworkSettings configuration. "NetworkSettings": { "Bridge": "docker0", "Gateway": "172.17.42.1", "IPAddress": "172.17.0.2", "IPPrefixLen": 16, "MacAddress": "02:42:ac:11:10:12", "PortMapping": null, "Ports": { "27017/tcp": null } } In this example, the IP Address is 172.17.0.2. So, to start a MongoDB shell connecting to the MongoDB,instance, run the following: $ docker run -i -t --name "mongoshell" --entrypoint "mongo" mongo 172.17.0.2 MongoDB shell version: 2.6.6 connecting to: 172.17.0.2/test Welcome to the MongoDB shell. For interactive help, type "help". For more comprehensive documentation, see http://docs.mongodb.org/ Questions? Try the support group http://groups.google.com/group/mongodb-user > You are now on the shell of the running MongoDB. You can now easily view the data at http://localhost:8000/. The color data is in the database named 'slsdb' in the 'colors' collection. >use slsdb switched to db slsdb >show collections colors system.indexes >db.colors.find() { "_id" : ObjectId("5485eb8a3b65a90017ea338e"), "color" : "#7DE6B6" } { "_id" : ObjectId("5485ebd03b65a90017ea338f"), "color" : "#1C3160" } { "_id" : ObjectId("5485ecfb3b65a9001a39cdce"), "color" : "#C8618C" } { "_id" : ObjectId("5485ee5d3b65a90026ff32d1"), "color" : "#973905" } { "_id" : ObjectId("5485ee5f3b65a90026ff32d2"), "color" : "#06076A" } { "_id" : ObjectId("5485ef643b65a9002fa9fcc6"), "color" : "#D5E272" } { "_id" : ObjectId("5485ef823b65a9002fa9fcc7"), "color" : "#9B459E" } { "_id" : ObjectId("5485ef863b65a9002fa9fcc8"), "color" : "#3C46EE" } I hope this practical demonstration helps to get you up and running with Docker quickly. Docker certainly is changing the landscape of DevOps, especially since we can reuse many pre-built containers, such as the MongoDB container used here.  This reuse minimizes the need for developers to invest time learning how to properly run or build such containers. Additional Resources Every two weeks, the SEI will publish a new blog post offering guidelines and practical advice to organizations seeking to adopt DevOps in practice. We welcome your feedback on this series, as well as suggestions for future content. Please leave feedback in the comments section below. Additional Resources To listen to the podcast, DevOps—Transform Development and Operations for Fast, Secure Deployments, featuring Gene Kim and Julia Allen, please visit http://url.sei.cmu.edu/js. To read all the installments in our weekly DevOps series, please click here or click on the links below. An Introduction to DevOps A Generalized Model for Automated DevOps A New Weekly Blog Series to Help Organizations Adopt & Implement DevOps DevOps Enhances Software Quality DevOps and Agile What is DevOps? Security in Continuous Integration DevOps Technologies: Vagrant DevOps and Your Organization: Where to Begin DevOps and Docker

Ryan Mallinson I’m Ryan Mallinson and I’ve been part of the DWP Digital Academy team for 18 months. I joined the team shortly before we welcomed the first Digital Academy in Leeds. The aim of the Digital Academy is to grow digital skills within DWP. Once graduated, the Academy students go on to work and, in some parts, form the teams driving digital developments. This is the immediate impact of the Academy. We are growing our own capability and sending people straight into the real world! We’ve had over 1000 people ‘touched’ by the Academy so far. Around 130 people have graduated from our Foundation course with the rest attending our 1-day ‘Discover Digital’ event. We brought around 120 graduates of the Digital Academy together on Friday 13 February to kick-start our community agenda. We want to take what we’re doing to a wider audience and collaborate with other government departments. We had graduates from the very (noisy) first Academy cohort - people who had gone on to lead digital development as Product Managers and Delivery Managers, right through to some of our newest graduates - Sandra Berry and Sommer Croft who had graduated the day before! Honest and thought-provoking When planning the day, I really wanted to get the ‘real ‘ picture of what life is like post-Academy. I gave each presenter their platform and they were a little surprised when I told them that it was theirs to do with as they please. From this we were presented with some very personal stories about what people had got out of the Digital Academy, and how it fit alongside their lives, whether that was a family bereavement or the arrival of a new child in the family. I couldn’t have hoped for more engaging and honest stories. People took to the stage and felt comfortable enough to not only talk about what worked well, but also the blockers they’d faced. It wasn’t a surprise that this included: Governance - the frustrations around getting approval and budget to run a Discovery Delays - the difficulties caused when a multi-disciplinary agile team has to be stood down or paused while the governance wheels turn from discovery to alpha, or alpha to beta. Using contractors to manage teams - the question of how people’s performance is managed and improved when this is being done by contractors who might not be familiar with our people performance approach. Dual reporting - in an agile team where stand-ups and show and tells are the way to find out what a team is doing, versus the need to fill in templates and progress reports to keep a wide and remote bunch of stakeholders up to date. Digital Academy user needs and backlog We had two interactive sessions where the graduates wrote the user needs and stories to improve the Digital Academy in future. Some of the themes were: Translating Academy learning to agile projects can be challenging IT and tools can be a blocker Graduates need to have some support so they can hit the ground running These themes came out again when we held a Q&A session with Kevin Cunnington, Sarah Cox and Annette Sweeney - with people asking how we can create a dynamic workforce of people with digital skills that can be deployed to discoveries or shared across different projects as and when priorities required. What next? We’re planning other blogs with first-hand accounts from our first cross-government Academy and we are only just dipping our toe into the cross-government digital community which is already starting to catch fire. We hope to continue these events and will be asking you to tell us what you want them to include. This is ‘Your Community, Your Voice’ and we want to hear it.

By C. Aaron CoisSoftware Engineering Team Lead CERT Cyber Security Solutions Directorate This blog post is the third in a series on DevOps, a software development approach that breaks down barriers between development and operations staff to ensure more effective, efficient software delivery. When Agile software development models were first envisioned, a core tenet was to iterate more quickly on software changes and determine the correct path via exploration—essentially, striving to "fail fast" and iterate to correctness as a fundamental project goal. The reason for this process was a belief that developers lacked the necessary information to correctly define long-term project requirements at the onset of a project, due to an inadequate understanding of the customer and an inability to anticipate a customer’s evolving needs. Recent research supports this reasoning by continuing to highlight disconnects between planning, design, and implementation in the software development lifecycle. This blog post highlights continuous integration to avoid disconnects and mitigate risk in software development projects. To achieve an iterative, fail-fast workflow, Agile methodologies encouraged embedding customer stakeholders full time with the development team, thereby providing in-house, real-time expertise on customer needs and requirements. In essence, Agile methodologies have created a constant, real-time feedback loop between customer subject matter experts and software development teams. In a previous post, I presented DevOps as an extension of Agile principles. Consistent with this definition, DevOps takes the real-time feedback loop concept and extends it to other points in the software development lifecycle (SDLC), mitigating risks due to disconnects between developers, quality assurance (QA), and operations staff, as well as disconnects between developers and the current state of the software. A cornerstone of DevOps is continuous integration (CI), a technique designed and named by Grady Booch that continually merges source code updates from all developers on a team into a shared mainline. This continual merging prevents a developer’s local copy of a software project from drifting too far afield as new code is added by others, avoiding catastrophic merge conflicts. In practice, CI involves a centralized server that continually pulls in all new source code changes as developers commit them and builds the software application from scratch, notifying the team of any failures in the process. If a failure is seen, the development team is expected to refocus and fix the build before making any additional code changes. While this may seem disruptive, in practice it focuses the development team on a singular stability metric: a working automated build of the software. Recall that a fundamental component of a DevOps approach is that to remove disconnects in understanding and influence, organizations must embed and fully engage one or more appropriate experts within the development team to enforce a domain-centric perspective. To remove the disconnect between development and sustainment, DevOps practitioners include IT operations professionals in the development team from the beginning as full team members. Likewise, to ensure software quality, QA professionals must be team members throughout the project lifecycle. In other words, DevOps takes the principles of Agile and expands their scope, recognizing that ensuring high quality development requires continual engagement and feedback from a variety of technical experts, including QA and operations specialists. For example, continuous integration (CI) offers a real-time window into the actual state of the software system and associated quality measurements, allowing immediate and constant engagement of all team members, including operations and QA, throughout the project lifecycle. CI is a form of extreme transparency that makes sure that all project stakeholders can monitor, engage, and positively contribute to the evolving software project without disrupting the team with constant status meetings or refocusing efforts. Due to their powerful capabilities, CI servers have evolved to perform (and therefore, verify) other important quality metrics automatically, such as running test suites and even automatically deploying applications into test environments after a successful integration. As DevOps practice matures, my expectation is that CI systems and tools will continue to evolve as a central management system for the software development process, as well as testing and integration. One of the research areas my team is exploring is ways to enhance software security by adapting effective security testing and enhancement tools to run efficiently within the constraints of CI, a topic I will explore further in the next installment of our ongoing series on DevOps. Continuous Integration in DevOps As I stated in the second post in this series, DevOps, in part, describes techniques for automating repetitive tasks within the software development lifecycle (SDLC), such as software builds, testing, and deployments, allowing these tasks to occur more naturally and frequently throughout the SDLC. I oversee a software engineering team that works within the SEI’s CERT Division that focuses on research and development of solutions to cybersecurity challenges. When developers on my team write code, they test locally and then check the code into a source control repository. We focus on frequent code check-ins, to avoid complex merge problems. After code is checked in, our CI system takes control. It monitors the source code repositories for all projects and pulls an updated version of the code when it detects a new commit. If the project is written in a compiled language (we use many different languages and frameworks regularly), the server compiles and builds the new code. The CI server also runs associated unit test suites for the project. If prior steps succeed, the server runs pre-configured scripts to deploy the application to a testing environment. If any of these processes fails, the CI server fails the build and sends immediate failure notifications to the entire project team. The team’s goal is to keep the build passing at all times, so a developer who breaks the build is expected to immediately get it back on track. In this way, the CI server helps to reinforce the habit of thoroughly testing code before committing it, to avoid breaking the build and disrupting the productivity of your team members. Without this QA process, a developer may check broken code into a central repository. Other developers may make changes that depend on this broken code, or attempt to merge new changes with it. When this happens, the team can lose control of the system’s working state, and suffer a loss in momentum when forced to revert changes from numerous developers to return to a functional state. CI servers (also known as build servers) automatically compile, build, and test every new version of code committed to the central team repository, ensures that the entire team is alerted any time the central code repository contains broken code. This severely limits the chance for catastrophic merge issues and loss of work built upon a broken codebase. In mature operations, the CI server may also automatically deploy the tested application to a quality assurance (QA) or staging environment, ensuring the Agile dream of a consistent working version of software. All the actions described above are performed based on automated configuration and deployment scripts written collaboratively by development and operations engineers. The collaboration is important—it ensures that operations expertise in deployment needs and best practices is represented in the development process, and that all team members understand these automated scripts and can use and enhance them. This collaboration also sets the stage for use of the same scripts to eventually deploy the system into production environments with high confidence, a process known as continuous deployment, which is a topic for a later post. As shown in the graphic below, the build server checks out new code from source control, compiles/builds it (if necessary), and tests the code (primarily unit tests, at this stage, though static code analysis is also possible). Once the code is tested, the build server deploys it to QA. At this point, the build server can also launch scripts to perform integration testing, user interface testing, advanced security testing (more on this soon) and other tests requiring a running version of the software. Consistent with Agile requirements that emphasize a continually working version of the software, our CI server automatically reverts to the last successful version of the software, keeping a working QA system available even if integration tests failed. With CI, when developers check in bad code, the system will automatically notify the entire team within minutes. This notification of failure can also be applied to failing functional tests, failing security tests, or failing automated deployment processes, creating an immediate feedback loop to developers to reinforce both software functionality and quality standards. This process helps the team to manage the development of complex, multi-faceted systems without losing sight of defects arising in previously completed features or overall quality. The CI process should be designed to reinforce the quality attributes most important to your system or customer: Is security a primary concern? Configure your build server to run a comprehensive suite of security tests and fail the build if vulnerabilities are found. Is performance a priority? Configure your build server to run automated performance tests to measure the speed of key operations, and fail the build if they are too slow (even if the operation completed successfully). Think of continuous integration as your gatekeeper for quality control. Design your failure rules to enforce continual adherence to the quality measures that are most important to your organization and your customers. Wrapping Up and Looking Ahead While CI is by no means a new phenomenon, the DevOps movement underscores its importance as a foundational technique for software process automation and enforcement. There are many popular CI systems, including Jenkins, Bamboo, Teamcity, CruiseControl, Team Foundation Server, and others. The variety of systems means that any team should be able to find a tool that both meets its needs and integrates well with the technology stack(s) it employs. For more information on this and other DevOps-related topics, every Thursday the SEI publishes a new blog post offering guidelines and practical advice to organizations seeking to adopt DevOps in practice. We welcome your feedback on this series, as well as suggestions for future content. Please leave feedback in the comments section below. Additional Resources To listen to the podcast, DevOps—Transform Development and Operations for Fast, Secure Deployments, featuring Gene Kim and Julia Allen, please visit http://url.sei.cmu.edu/js.