By Matt Small, Head of Customer Success
Application Packaging is probably not something you’re familiar with hearing about as part of a “CI/CD process.” Most companies that are working towards full DevOps automation feel that as long as the Dev side and the Ops side are automated independently, tying those two processes together is all that’s needed. However, that is a challenging problem when you’re dealing with a heterogeneous collection of team-selected tools in your tool chain. Enterprises that encourage Development and Operations teams to select the best tools for the job are getting stuck trying to implement policies and best practices that can handle that heterogeneity. This heterogeneity in tooling and the rapid pace at which that tooling is changing also means the beginning of the end for the full-stack developer in the Enterprise. It’s just not feasible for someone to know it all well enough to enforce it all.
New, container-centric CI tools that leverage the relative simplicity that container abstraction provides try and merge the two entirely: a check-in of code will automatically deploy that code. While that’s the ideal approach to automation, it ignores both legacy premise-based infrastructure as well as evolving trends in the industry toward PaaS and FaaS. As new applications are built and as old ones are modernized, they too will be heterogeneous in nature and designed to take advantage of the best-fit cloud services.
That’s a lot of of technical complexity and distributed tribal knowledge that must be managed just to answer the questions “what is this application, how does it run, and is it up to date?”
A logical place to answer that question is in the Application Package. If done correctly, Enterprises now have a way to define their infrastructure in an application-centric way, inclusive of the code, the dependencies, the configuration and the orchestration required to deliver that application. This is how Bitnami Stacksmith handles application packaging. Developers, Security and Operations continue to use their tooling of choice to trigger the process, and Application Packaging automation pulls in the required Artifacts and Assets from their trusted sources to create deployment ready outputs that can be picked up downstream.
 |
| Examples of ways to integrate application packaging and maintenance with your CI / CD tools |
In practice, Developers push their code to their CI tool of choice and may also contribute their application dependencies and configuration logic as scripts in their source control management tool of choice. Information Security teams maintain OS hardening process and other security policies as scripts or orchestration templates. Operations contributes best practices, reference deployment automation, and prefered cloud service configurations and defines their preferred Template and image output formats. A new contribution from any team triggers a repackaging process, ensuring that the resulting Templates, Images, Containers and PaaS integrations are continuously maintained and up-to-date.
In addition to team-provided changes, updates and changes to the OS and application system packages, dependencies, and any related CVEs should also prompt a repackaging. This tightens the refresh cycle and ensures that the process can be made continuously secure.
The package is an immutable and versionable point in time in an application’s lifecycle. It promotes best practices in testing, providing the ability to launch and test against all components of the application as a complete package. It facilitates in-place application upgrades using native cloud orchestration tooling as well as leveraging blue-green release process or canary deployments by recreating net-new deployments for a full refresh. It also simplifies roll-back, allowing previous application packages to be completely redeployed.
Logging the image creation process gives you a detailed record of the event and every step of the process, as well as a manifest of everything that was packaged into the images or containers and is now immutable. These logs and manifests provide important assurances to the organization: assurance that everyone’s contributions are verifiably included, that the IT infrastructure is auditable, and that no affected library is left unpatched in the event of a critical vulnerability.
As the cloud continues to rapidly evolve with more services and functions, as tooling continues to evolve with new strategies and optimized approaches, the Application Package remains at the center of the DevOps handoff, providing the needed flexibility for application and infrastructure stakeholders to leverage their own best-fit tools and services while enforcing the policies and best practices that are important to them.
Want to learn more? Watch the recording of our latest demo here.