You really need 2-3 tools and practices to ensure your delivery team is leveraging Continuous Integration (CI). In the Deep Cut CI article, I’ll break down even further how to establish Continuous Integration for an enterprise, taking into account security, policies, auditing, controls, activity expiry, quality and much more.
Depending on your organization, this may be mission critical. While the delivery team can capture work without a project/task management tool, it’s good for leadership and non-technical folks to be able to see in layman’s terms what the delivery team is working on. In the Deep Cut series, we’ll go into how you can integrate your tools so that version control, builds, testing, and deployment status can be reflected on the work items within such tools. In other words, you can track exactly where and how well a change is doing just by looking at its associated ticket. We’ll also highlight how bi-directional automation can achieved so that activity with one tool triggers or is dependent on activity within other tools. Examples of Project/Task management tools include: Jira, VersionOne LifeCycle, Trello, Microsoft Team Foundation Server. Check out our article that compares the Project/Task Management tools.
Source Code Management (SCM)
The true technical starting point of CI. The SCM is the central repository where all your engineering team can maintain their working assets (think code, network/database/operational scripts). While for the non-technical folks of your organization the Project/Task Management tool is the Command/Control Center of your delivery, for the technical folks, the SCM is the Control Center. Your SCM platform will receive the latest changes from your engineering team. Based on the process you have established, they can commit code changes directly to trunk or through a set of controls, have their changes on a separate branch run through builds and tests before being integrated into trunk. CI Deep Cut will address your different options in handling this. The SCM can also facilitate code reviews (which is highly recommended), allowing another team member review and approve code changes before it’s integrated into trunk. Even better, a bot can review the changes to ensure certain pre-established criteria is met before merging into trunk. As a technical Command/Control Center, the SCM tool integrates with the CI server and can initiate a build or test in the event of checked-in changes. It can also send notifications and activity information directly to team emails or a chatroom.
Assuming the version control technology of choice is git, examples of SCM platforms are Github, Gitlab, Bitbucket, and Team Foundation Server. Some of these tools even provide activity charts to let you visualize team and project activity. Check out our article that compares the SCM tools.
The CI server as its name implies is where Continuous Integration really happens. Builds, tests, deployments, notification, artifact management, release management, code coverage, security scans, database refresh, and infrastructure setup and teardown are some of the things that can happen on a CI server. While the SCM tool is the Command/Control Center, you can think of the CI server as the rocket launching the spacecraft into space. Again, the Deep Cut series on CI provide details on many use cases of a CI server. However for this article, the essentials are builds, tests, notification and release candidacy or readiness. Based on your release cycle, you may want to run builds after each code check-in to the central repository, or you may want to schedule your integration (say after business hours). All CI servers are flexible in the regard. They all can also send out notifications to chat rooms or intended teams on the status of their activity when completed. Examples of a CI server includes: Jenkins, Bamboo, Circle CI, Microsoft Visual Studio Team Services (VSTS), Travis CI, Go, Gitlab. Check out our article that compares the CI servers.
True CI contains either one of these agile practices. Your teams should use either Scrum or Kanban to manage their work, control work intake, reflect what’s in progress, and be clear when done. Operational teams can benefit from a simple Kanban board that tracks To Dos, In Progress and Done statuses of work items. Scrum boards can be used for development and testing teams that will require more elaborate columns.
Some organizations still think version control is exclusive to the development team. Not the case. Your organization should encourage all working assets that can affect production to be tracked. Your operational, database, networking scripts are good examples of assets that can be version controlled. Actually, in the DevOps handbook, the recommendation is for all working assets to live in the same repository. That may be blasphemous in your organization, but it’s worth the thought.
Version Control Workflow
It should be noted however that simply leveraging version control isn’t enough. You’ll want to establish some ground rules for how you use version control otherwise it can become a nightmare to manage. Before embarking on a workflow, your organization needs to decide if it wants to do trunk-based or feature-based management. There’s a set of guidelines for both. Refer to the references section for more details.
While this is not an exhaustive list, as mentioned earlier, the Deep Cut CI article will attempt to cover even more detail